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The  primary  goal  of  this  research  effort  was  to  develop 
a  domain  independent  activity  scheduling  algorithm  that 
would  be  able  to  handle  ad-hoc  constraints. 


The  activity  scheduling  problem  is  one  of  assigning  tasks 
(activities)  to  objects  (jobs)  while  adhering  to  time  and  re¬ 
source  constraints.  Operations  researchers  originally  had  ap¬ 
proached  the  problem  using  mathematical  programming 
techniques.  This  approach,  however,  is  poor  at  solving  real 
world  problems.  Real  World  problems  tend  to  be  very  large 
and  are  often  too  complex  to  represent  numerically. 
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An  algorithm  is  presented  that  is  based  on  an  heuristic 
search  paradigm.  It  uses  symbolic  constraints  to  assist  the 
search  process.  Functionally,  the  task  is  similar  to  that  of 
linear  programming.  Hie  scheduling  problem  is  represented 
as  a  group  of  variables.  Each  variable  has  a  corresponding 
set  of  possible  values,  called  a  value  set.  The  aim  is  to  assign 
each  variable  a  value  from  its  value  set  while  adhering  to 
the  imposed  constraints.  The  difference  is  that  symbols 
rather  than  just  numbers  are  dealt  with.  In  so  doing,  the 
constraints  are  able  to  capture  the  nuances  of  complex 
domains. 

A  pattern  directed  constraint  definition  language  called 
CDL-II  is  presented.  The  language  is  based  on  set  theoretic 
operators  and  allows  one  to  input  constraints  in  an  ad  hoc 
fashion.  The  constraints  are  used  to  prune  the  search 
space  through  the  mechanisms  of  constraint  generation, 
posting  &  propagation. 
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Preface 


Introduction 

This  thesis  is  an  effort  towards  the  development  of  a  domain  independent  activity  scheduling 
algorithm  that  can  handle  ad-hoc  constraints.  By  combining  the  techniques  of  Artificial  Intelligence 
and  Operations  research,  a  program  has  been  developed  that  performs  scheduling  using  a 
constraint  assisted  search  approach.  The  program  has  a  high-level  constraint  definition  language 
which  allows  the  user  to  input  ad-hoc  constraints. 

Activity  scheduling  is  the  problem  of  assigning  certain  objects  (jobs)  to  tasks  (activities)  while 
adhering  to  time  and  resource  constraints.  It  is  a  popular  area  in  Operations  Research  circles 
Operations  researchers,  however,  have  been  unable  to  solve  large  real  world  scheduling  problems 
through  mathematical  programming  techniques.  Consequently,  the  whole  area  of  heuristic 
scheduling  has  come  to  play  an  important  role  in  this  problem  domain. 

Several  heuristic  scheduling  programs  have  been  built.  These  programs  tend  to  have  the 
specifics  of  the  associated  domain  hard-wired  into  the  program.  The  only  flexibility  that  these 
programs  allow  is  the  ability  to  change  a  few  parameters  in  the  constraint  set.  If  a  new, 
unanticipated  constraint  is  encountered,  the  program’s  code  needs  to  be  changed.  This  is  often  not 
easily  done. 

To  handle  this  problem,  we  present  a  constraint  definition  language  called  CDL-1I.  It  allows 
the  user  to  modify  old  constraints  and  add  new  ones  at  will.  For  example,  let  us  consider  the 
domain  of  job  shop  scheduling.  The  typical  inputs  to  the  system  are  the  different  jobs,  the  due 
dates,  the  quantities  to  be  produced  etc.  Each  job  shop  presumably  has  constraints  which  need  to 
be  adhered  to.  These  constraints  may  range  from  due  dates  to  machine  preferences  to  problems 
regarding  resource  availability.  Such  constraints  are  not  static  and  are  ever  changing.  These  new 
constraints  may  be  of  a  totally  unanticipated  nature  and  would  traditionally  have  been 
incorporated  by  painfully  changing  the  original  code.  On  the  other  hand,  our  framework  allows  one 
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to  just  write  the  constraint  in  CDL-H  and  enter  it  into  the  computer. 

The  algorithm 

The  techniques/technologies  which  have  played  an  important  role  in  the  development  of  the 
ideas  in  this  thesis  are: 

a)  Branch  and  Bound  Algorithms  (from  OR) 

b)  Planning  Research  (from  AI) 

c)  Constraint  Analysis  (from  AI) 

d)  Search  paradigms  and  backtracking  (from  AI) 

The  algorithm  presented  in  this  thesis  is  based  on  the  search  paradigm.  It  uses  constraints  to 
prune  the  search  space.  Instead  of  following  the  branch  &  bound  technique  it  has  a  prune  and  then 
branch  &  bound  flavor. 

This  is  done  by  using  the  constraints  through  the  processes  of  generation,  posting  and 
propagation.  The  constraints  are  written  in  a  constraint  definition  language  called  CDL-1I.  CDL-II  is 
a  production  rule  type,  pattern  directed  language.  This  language  is  based  on  the  set  theoretic 
operators:  intersection,  difference,  restriction  and  union.  The  other  feature  of  CDIr-II  which  has 
proved  valuable  is  the  ability  to  write  constraints  which,  in  turn,  write  constraints.  This  process  of 
constraint  generation  is  also  pattern  directed. 

Currently  the  implementation  uses  chronological  backtracking.  Even  though  the  scheduler 
uses  contexts  for  the  development  of  different  branches,  we  have  not  used  dependency  directed 
backtracking  [Sussman,  1978],  This  is  because  our  domain  is  not  well  suited  for  intelligent 
backtracking.  This  is  in  contrast  to  Sussman  &  Stallman’s  work  wherein  intelligent  backtracking  is 
facilitated  by  the  scientific  principles  that  govern  the  behavior  of  the  objects  in  their  domain, 
namely,  electrical  circuits. 
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Thesis  Reader's  Manual 


The  domain  that  has  been  chosen  is  that  of  Army  Training  Scheduling.  The  thesis  starts  off 
with  a  scenario  (Chapter  1)  which  describes  the  problem.  The  sce>  ario,  though  anecdotal  in  nature, 
is  representative  of  the  problem  and  its  complexity. 

The  second  chapter  introduces  the  problem  and  reviews  the  relevant  literature. 

The  rest  of  the  chapters  discuss  the  use  of  constraints  for  activity  scheduling.  Two  different 
implementations  have  been  presented.  The  first  implementation  uses  the  constraints  passively 
(chapter  III).  The  constraints  are  used  only  for  bounding  the  search.  Such  bounding  is  done  only 
after  the  branching  step  is  taken.  Chapter  Hi  introduces  a  crude  constraint  definition  language 
called  CDIi-l.  It  will  be  shown  how  CDL-I  fails  to  capture  the  complexity  of  the  problem  and  how 
the  passive  use  of  constraints  is  not  a  good  approach. 

NOTE:  To  understand  the  syntax  of  CDL-I  &  CDL-ll  the  reader  is  advised  to  peruse  the 
IMST  manual  (APPENDIX  A).  This  manual  describes  the  notion  of  an  asstrlional  database  and 
explains  the  use  of  the  IMST  production  rule  language.  CDL-ll  is  completely  written  in  IMST. 

Having  dispelled  the  concepts  related  to  the  passive  use  of  constraints  the  thesis  enters  into  a 
discussion  about  the  active  use  of  constraints.  Chapter  IV  introduces  the  ideas  behind  this 
technique.  It  builds  an  intuitive  feel  for  how  constraints  can  be  used  for  pruning  the  search. 

Chapter  V  continues  the  discussion  on  the  active  use  of  constraints  and  goes  on  to  describe 
the  workings  of  the  second  implementation.  This  implementation  is  based  on  a  constraint  definition 
language  called  CDL-ll.  This  language  is  entirely  built  in  the  IMST  r  .vironment  (Appendix  A). 

Appendix  B  presents  a  trace  of  the  program  run. 

The  author  has  assumed  that  the  reader  is  familiar  with  planning  research  and  constraint 
analysis.  Here  are  a  few  papers  that  this  thesis  draws  from.  They  make  excellent  background 
reading . 

1)  Fikes  R.E.  (1970)  "REF-ARF  :  A  System  for  Solving  Problem--  Stated  as  Procedures.”  Int. 
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J.  of  AI  (1970)  1:27-120 


2)  Stefik  M.  (1981)  “Planning  with  Constraints  (MOLGEN:  Parti),”  Int.  Journal  of  Artificial 
Intelligence,  Vol  16,  pp  111-140. 

3)  Sussman  G.J.,  Steele  G.L.  (1980)  "Constraints:  A  language  for  expressing  almost 
hierarchical  descriptions  ”,  Int.  Journal  of  Artificial  Intelligence  14:1-39. 

4)  Fikes  R.E.  and  N.J.  Nilsson  (1971)  "STRIPS:  A  new  Approach  to  the  Application  of 
Theorem  Proving  to  Problem  Solving”,  Int.  Journal  of  Artificial  Intelligence,  Vol  2  pp  189-208. 
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Chapter  I 


A  Scenario 

This  chapter  sets  the  stage  for  the  application  domain  used  in  this  thesis.  An  anecdotal 
description  of  the  domain  is  presented.  It  is  representative  of  the  complexity  we  had  to  deal  with. 
We  have  also  tried  to  give  the  reader  a  flavor  of  the  kind  of  expertise  current  domain  experts 
possess. 

A 

John  Dale  stood  at  the  window  watching  trucks  pass  by.  The  air  reeked  of  diesel  and  dust 
from  the  parched  land.  In  his  twelve  years  as  range  officer  at  Ft.  Kami’s  Firing  Range  he  had  never 
seen  such  an  influx  of  troops  for  fall  training.  Since  the  authorities  had  decided  to  move  several 
battalions  of  the  5th  Mechanized  Infantry  Division  (Ml)  demand  for  firing  ranges  had  been  rising. 
The  move  was  to  be  completed  over  the  next  few  months,  "things  are  going  to  get  tougher"  he  said 
to  himself. 

In  the  distance,  he  could  hear  the  sound  of  M-l  tanks  firing  at  practice  targets.  The  schedule 
on  the  wall  told  him  that  it  was  battalion  20  of  the  5th  MI  Division  on  range_9.  The  convoy  that 
had  just  passed  the  field  office,  22  trucks  of  troops,  were  all  headed  for  M-16  training  on  range_8. 
John  Dale  took  great  pride  in  his  work  and  his  acquired  expertise  in  range  scheduling  and 
coordination.  The  boys  who  just  passed  him  were  headed  for  range_8,  but  he  knew  it  would  be 
safe  even  though  tanks  were  training  in  the  adjaeent  range.  Everything  had  been  worked  out,  the 
firing  directions,  the  safety  spans  and  the  schedule  conflicts. 

John  was  concerned  about  the  problems  the  new  battalions  might  bring.  He  was  going  to  be 
up  against  a  very  tough  resource  problem.  The  next  master  schedule  was  due  in  a  month,  and  he 
anticipated  problems  with  having  to  schedule  so  many  more  battalions. 

The  operations  research  group  down  at  Ft.  Kami  had  been  helping  John  prepare  the  master 
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plan  every  quarter.  He  would  send  them  a  listing  of  all  the  battalions  and  the  amount  &  type  of 
training  activities  to  be  carried  out  by  each  battalion.  A  schedule  would  be  returned  in  under  ‘2 
weeks. 

The  schedule  was  not  always  very  useful.  It  did  not  take  into  consideration  all  those  real-lift 
problems  that  cropped  up  time  and  again.  John  remembered  the  time  he  spent  with  Mark  Maser,  a 
young  eager  systems  analyst  from  Ft.  Kami.  He  had  told  Mark  all  about  the  firing  ranges  and  rules 
of  thumb  used  in  scheduling.  He  had  told  him  about  how  certain  activities  can  be  carried  out  only 
on  certain  ranges  and  how  the  safety  span  considerations  can  change  the  way  a  schedule  is  built. 
Mark  had  been  a  good  listener  and  sure  enough,  he  came  back  in  3  months  with  a  really  impressive 
scheduling  program.  Since  then  whenever  John  had  had  some  new  requirements  he’d  just  call  up 
Mark  and  the  changes  would  be  made  in  a  matter  of  days.  Mark  was  gone  now,  had  found  a  job  in 
Silicon  Valley.  There  was  nobody  to  make  changes  anymore.  The  other  programmers  never  seemed 
to  have  the  time,  nor  did  they  seem  to  understand  the  nuances  of  the  problem  at  hand. 

B 

The  phone  was  ringing,  John  turned  around  to  watch  his  assistant  Fred  Rufus  pick  up  the 
phone.  Fred  reached  for  a  pad  and  started  making  quick  notes.  It  was  that  time  of  the  quarter 
when  the  battalions  filed  their  training  request  forms.  A  training  request  form  containes 
information  about  the  training  activities  the  battalion  wishes  to  perform,  including  preferences 
about  timing  and  precedences.  Many  officers  called  in  by  phone  to  relay  some  exceptions  and 
special  requirements.  Fred  walked  up  to  the  scheduling  board  and  stood  there  looking  intently  at 
He  scratched  his  head. 

John  Dale  looked  on.  Fred  was  quickly  becoming  adept  at  his  work,  but  not  good  enough  to 
be  allowed  to  make  any  changes  without  an  endorsement  from  John.  Fred  better  learn  the  ropes 
soon  enough.  It  took  John  several  years  before  he  could  get  a  handle  on  all  the  considerations 
required  to  run  a  firing  range  safely  and  smoothly.  He  knew  the  ranges,  their  characteristics;  the 
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weapon  systems  and  their  characteristics  like  the  back  of  his  hand.  Ilis  first  and  foremost  concern 
was  safety,  never  should  two  battalions  be  scheduled  to  work  on  the  same  firing  range  on  the  same 
day.  Every  time  he  scheduled  a  training  activity  he  had  to  make  sure  that  the  safety  spans  of  the 
current  weapon  system  did  not  interfere  with  any  other  training  activity  scheduled  on  an  adjoining 
range.  He  had  all  this  information  on  his  finger  tips.  Fred  still  had  to  refer  to  the  range  maps  and 
safety  span  traces  to  schedule  an  activity. 

John  walked  up  to  Fred,  "What's  the  matter  Fred?  " 

"  Captain  Roger  Mason  of  battalion  twenty-six,  MI  four  called  in  and  said  that  he  would  like 
his  men  to  train  with  battalion  9  of  MI  three  for  Mortar  firing  next  quarter.” 

"Two  battalions  together?  That's  something  new" 

’  Battalion  26  of  MI  four  is  scheduled  for  Mortar  on  range  22  for  the  first  week  of  December, 
but  battalion  17  of  the  fifth  MI  are  on  range21  during  that  period.  I  cannot  figure  out  how  I  can 
get  26  and  9  on  adjoining  ranges." 

"Why?" 

"For  one  thing,  range23  is  not  suited  for  Mortar  fire  and  range  21  is  the  only  choice” 

John  cut  in,  "Can  you  move  battalion  17  elsewhere?” 

"No,  they  had  requested  completion  of  Dragon  Qual  before  Christmas  and  I  do  not  see  any 
other  free  time  windows." 

It  was  a  tough  problem.  John  wished  Mark  was  around.  He  could  have  just  called  Mark  and 
told  him  about  the  change.  He  remembered  the  time  when  Central  Training  Command  (CTCOM) 
had  issued  an  order  to  perform  cyclic  training.  CTCOM  had  found  that  certain  training  activities 
are  most  effective  when  carried  out  in  a  cyclic  basis.  That  is,  the  total  annual  amount  of  training 
on  certain  activities  was  to  be  divided  into  5  or  6  sessions.  Each  session  was  then  to  be  scheduled 
such  that  no  two  sessions  were  less  than  one  month  apart  nor  were  they  more  than  2  months  apart. 
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It  took  Mark  two  weeks  to  make  this  change.  John  shuddered  at  the  thought  of  what  might 
happen  if  a  directive  as  radical  as  the  cyclic  one  were  to  be  sent  out  by  CTCOM  today.  John 
longed  for  a  system  that  would  be  able  to  handle  ad-hoc  requirements. 

c 

John  walked  back  to  his  desk  to  finish  up  a  Memo  he  was  preparing  for  CER1.  (the  Corps  of 
Engineer’s  Construction  Engineering  Research  Lab.).  Two  researchers  from  CERL  had  come  over 
last  week  to  discuss  the  development  of  a  Intelligent  Scheduler  which  would  be  able  to  handle 
ad-hoc  requirements.  They  had  told  him  about  how  the  scheduler  would  be  able  to  handle  changes 
and  would  store  all  the  rules  of  thumb  he  was  trying  to  teach  Fred. 

John  was  preparing  a  memo  describing  the  scheduling  problem  in  the  form  of  a  small 
representative  example.  He  was  to  include  a  list  of  constraints. 

The  afternoon  wore  on,  trucks  were  rolling  past  the  range  office.  John  Dale  was  smiling,  he 


had  just  finished  the  Memo: 


D 


MEMORANDUM 

From:  John  Dale,  Range  Officer,  Ft.  Kami 
To:  Bob  James,  CERI. 

Date:  April  2,  1985 

Here  is  a  small  representative  example  of  the  scheduling  problem.  I  have  included 
constraints  as  you  had  requested. 

Consider  a  firing  range  having  three  ranges: 
range_  A 
range_FJ 

and  range_C 

Refer  figure  l.l 


There  are  three  battalions: 
bat_  A 
bat  _  B 
bat_C 

and  there  are  three  activities: 
act_A 
act_B 
act_C 

Let  us  assume  a  time  period  of  two  weeks: 

days  =  {123456789  10  11  12  } 

N'ow  we  have  several  constraints  on  the  problem: 

Constraint:  Cl 


some 
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A  battalion  can  do  only  one  activity  in  one  lime  period 
(usually  a  day). 

Constraint:  C2 

Conflicts:  There  shall  be  only  one  battalion  on  a 
particular  range  on  a  particular  day. 

Constraint:  C3 

If  any  battalion  is  scheduled  for  activity  act_B 

then  that  battalion  should  not  be  scheduled  for  anything 

on  the  very  next  day.  This  is  because  act_B  is  very  exabusting. 

Constraint:  C4 

There  are  only  certain  ranges  that  can  host 
certain  activities. 

Constraint#  Activity  Legal  Ranges 

C4_one  act_A  range_A  range_B 

C4_two  act_B  range_C 

C4_three  act_C  range_B 


Constraint:  CS 

The  battalions  shall  perform  the  activities 
according  to  the  following  frequences: 


activity 


act 

_  A 

act_B 

act 

1 

> 

3 

0 

0 

bat_B 

1 

1 

1 

» 

e* 

1 

o 

1 

2 

0 

Constraint:  C8 
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,  There  is  a  cyclic  constraint  on  activity  act_A. 

I  This  means  that  a  battalion  should  perform  act_A  at 

regular  intervals.  If  the  first  schedule  date  is  x 
>  then  the  next  date  should  be  after  x+2  but  before  x+4. 


Constraint:  C7 


r 


Safety  spans:  When  act_A  is  carried  out  on  range_A, 
the  safety  spans  requires  that  it  is  unsafe  to  schedule 
anything  on  range_C. 
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Chapter  II 


INTRODUCTION 

II.O  Introduction 

In  this  chapter  we  shall  set  the  stage  for  the  intelligent  use  of  constraints  in  scheduling 
problems.  We  shall  also  review  the  relevant  literature  with  includes  references  from  both  Artificial 
Intelligence  and  Operations  Research. 

Scheduling  had  originally  been  looked  upon  as  a  problem  suited  to  mathematical 
programming  techniques.  This,  however,  is  not  true;  the  complexity  and  size  of  real-world 
scheduling  problems  has  moved  research  towards  more  tractable  algorithms  involving  heuristic 
search  paradigms.  Our  hypothesis  is  that  a  domain  independent  scheduler  can  be  built  which 
would  only  use  constraints  to  guide  the  search.  Scheduling,  per  se,  has  been  tackled  by  several 
researchers  in  AI,  the  most  significant  application  is  a  system  for  Job-Shop  scheduling  called  ISIS  [ 
Fox  M  S.,  198.1], 

We  would  like  to  remind  the  reader  that  scheduling  has  been  researched  by  Management 
Scientists  and  Operation  Researchers  for  several  years.  Some  very  promising  results  have  emerged 
form  such  work.  We  now  embark  upon  a  survey  of  some  of  the  work  relevant  to  our  interests. 

II.  1  Literature  Review 

Parts  of  this  section  (II. I)  has  been  adapted  from  |Fox,  M.S.  198,1]: 

Management  Science 

"Management  science  research  in  scheduling  has  focussed  on  understanding  the  variety 
of  scheduling  environments  that  exist,  and  constructing  s  heduling  algorithms  specific  to 
them.  Four  types  of  "shops"  are  distinguished  in  the  literature: 

*  single  machine  -single  operation 

*  parallel  machines  -  single  operation 

*  flow  shop  series  of  machines  -  multiple  operations 

*  job  shop  network  of  machines  -  multiple  operations 

A  job  is  defined  as  having. 
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*  one  or  more  operations 

*  a  processing  time  for  each  operation 

*  a  due  date 

And  the  utility  of  scheduling  is 

measured  in  terms  of: 

*  lateness 

*  flowtime 

*  tardiness 

*  makespan 

It  was  recognized  early  in  management  science  that  scheduling  is  an  example  of  a 
constraint  satisfaction  problem  which  could  be  optimally  solved  using  mathematical 
programming  techniques.  Integer  programming  approaches,  while  theoretically  valid  are 
useless  practically.  One  branch  of  research  focuses  on  the  attainment  of  optimal  results, 
but  algorithmic  complexity  has  restricted  these  results  to  the  one  and  two  server  cases. 

The  achievement  of  these  results  requires  the  removal  of  much  of  the  constraints,  and  the 
focus  on  single  criterion  for  measuring  schedule  efficacy.” 

Artificial  Intelligence 

The  area  of  Planning  Research  is  the  most  relevant  part  of  Artificial  Intelligence  to 
scheduling  problems.  The  basic  idea  of  using  search  to  perform  problem  solving  has  been  used  both 
by  AI  researchers  and  by  Operations  Researchers.  The  use  of  Constraints  in  Planning  research  has 
proved  very  promising  (Stefik  Mark,  1981).  Search  is  carried  out  within  a  space  of  possible  solution 
states  for  a  state  that  satisfies  a  set  of  pre-specified  requirements.  A  state  can  be  changed  into 
another  state  by  applying  a  heuristic  operator  to  it.  Planning  can  be  viewed  as  a  form  of  heuristic 
search.  The  first  problem  in  creating  a  planning  system  is  to  generate  the  states  relevant  to 
reaching  the  goal. 


"Given  a  description  of  the  initial  state,  goal  state,  and  a  set  of  operators,  the 
operators  can  be  iteratively  applied  to  the  initial  state,  and  its  solution  path  of  operations, 
or  plan.  Depending  on  the  ’strength’  of  the  operators,  the  space  elaborated  can  be  large  or 
small;  however  the  better  heuristics  generate  smaller  search  spaces  and  find  the  solution 
faster.  Planning,  and  related  research,  has  focussed  on  a  number  of  issues:  for  instance, 
choosing  the  state  to  elaborate  next,  choosing  which  operator  to  expand  a  state,  and 
choosing  alternative  state  representations  and  operators.” 

Robot  planning  is  the  most  popular  area  in  planning  research.  The  STRIPS  system  (Fikes  & 
Nilsson,  1971)  represented  operators  with  pre  and  post  conditions. 
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This  thesis  has  borrowed  several  ideas  from  a  constraint  analysis  system  called  RKF-ARF. 
(Pikes,  1970).  Its  task  was  similar  to  that  of  linear  programming.  Given  a  set  of  linear  equations  as 
constraints,  it  makes  value  assignments  for  all  the  variables.  Instead  of  doing  a  brute  force  search 
for  a  set  of  bindings  that  satisfies  all  the  constraints  (equations),  it  used  the  constraints  to  reduce 
the  generated  binding  set.  Hence,  the  system  can  be  viewed  as  a  classical  generate  and  test,  where 
the  system  was  able  to  take  the  constraints  and  use  them  in  the  generator  to  reduce  the  size  of  the 
search  space.  This  thesis  is  an  extension  of  REF-ARF  wherein  the  constraints  are  symbolic  in 
nature  and  are  pattern  directed. 

After  the  work  on  STRIPS  came  a  very  important  and  interesting  planning  program  called 
NOAH  (Earl  Sacerdoti  1975).  By  using  hierarchical  plan  generation,  Sacerdoti  was  able  to 
implement  an  intelligent  planner.  Taking  a  cue  from  NOAH,  Austin  Tate  (Tate  A,  1977)  developed 
NONLIN.  It  is  a  non-linear  planner  for  generating  Project  Networks. 

At  about  the  same  time  some  very  interesting  Constraint  Analysis  work  was  in  progress  at 
MIT.  Stallman  &  Sussman  (1978)  developed  the  concept  of  dependency  directed  backtracking.  A 
electrical  circuit  analyzer  called  EL  was  developed.  EL  used  the  concepts  of  constraint  posting  and 
propagation  together  with  intelligent  backup. 

In  1981-82  Mark  Stefik  worked  on  an  Intelligent  Planner  called  MOLGEN  (Stefik  1981).  It  is 
a  planner  for  Genetic  Experiments.  MOLGEN  uses  constraints  through  the  processes  of  generation, 
posting  and  propagation.  This  work  was  one  of  the  most  significant  contributions  to  symbolic 
constraint  propagation. 

There  are  only  a  few  Al  scheduling  systems: 

"....  One  of  the  few  AI  scheduling  systems  was  in  the  domain  of  train  scheduling 
(Fukumori,  1980).  It  used  a  constraint-based  approach  to  determine  the  arrival  and 

departure  times  of  trains . A  second  AI  scheduling  study  was  that  of  Vere  (1981).  In  it 

plans  are  constructed,  and  times  associated  with  each  step  in  the  plan.  A  sophisticated 
algorithm  for  time  propagation  based  on  interactions  is  described.” 

A  third  system  is  ISIS,  a  factory  shop-floor  scheduler.  It  is  a  constraint  directed  search 
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program  which  use*  beam  search  to  generate  schedules.  (Fox  M.S.  1983) 

Lastly  there  is  a  Intelligent  Scheduling  Assistant  (ISA)  project  underway  at  the  Al 
Technology  Center  at  DEC.  It  is  a  rule  based  scheduler  and  is  built  in  OPS-5.  (  Orciuch  Ed,  Frost 
John,  1985] 
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II. 2  Current  Methodologies 

In  this  section  we  shall  describe  two  existing  approaches  to  the  scheduling  problem.  The  first 
one  is  a  branch  and  bound  method  used  for  producing  optima!  schedules  for  a  multi  resource- 
constrained  case.  The  second  is  a  constraint  directed  search  methodology  used  for  Job  Shop 
scheduling. 

II.2.1  Branch  Sc  Bound  [  Stinson  Joel,  et.al.  1978] 

The  Stinson  algorithm  uses  a  branch  and  bound  cycle  to  develop  a  tree  of  choice  nodes.  In 
order  to  keep  the  problem  of  tractable  size,  pruning  is  carried  out  using  : 

-  Dominance  Principles 

•  Lower  bound  pruning. 

As  the  search  tree  is  being  expanded,  dominance  rules  prune  off  nodes  that  are  statically  inferior  to 
other  generated  nodes  or  are  subsets  of  them.  Once  a  set  of  candidate  nodes  are  generated  it  is 
pruned  using  a  lower  bound  estimate  to  complete.  This  estimate  is  calculated  using  heuristic 
projection  techniques. 

As  long  as  the  estimate  to  complete  is  a  lower  bound  on  the  real  completion  time,  the 
algorithm  can  be  guaranteed  to  give  optimal  results. 

The  major  problem  with  such  an  approach  is  that  it  cannot  handle  ad-hoc  or  complicated 
constraints.  Our  research  efforts  are  toward  a  system  which  can  handle  any  realistic  constraint  that 
is  tossed  at  it. 

n.2.2  Constraint  Directed  Search 

(Fox,  1983] 

The  ISIS  system,  built  at  the  Robotics  Institute  of  the  Carnegie-Mellon  university,  performs 
constraint  directed  heuristic  search;  constraints  are  used  to  bound  and  guide  the  search 
(scheduling)  process. 

We  shall  now  describe  the  process  of  constraint  directed  search.  The  methodology  described 
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here  may  look  similar  to  that  of  ISIS.  This  discussion  however,  is  not  an  attempt  to  explain  ISIS,  it 
is  an  attempt  to  familiarize  the  reader  about  the  current  technique-  used. 

Consider  a  scheduling  problem  wherein  several  jobs  need  to  '  heduled  in  a  machine  shop. 
Each  job  has  a  set  of  activities  that  need  to  be  carried  out  on  it  "  e  activities  are  essentially  a 
sequence  of  operations  to  be  carried  out  on  several  machines. 

We  start  the  scheduling  by  picking  up  the  job  with  the  highest  priority  and  start  scheduling 
it.  While  scheduling  a  job  we  start  with  its  first  operation,  say  'opl'.  It  is  possible  that  ’opl’  may 
be  carried  out  on  one  of  several  machines.  To  represent  such  choices  a  activity-network  for  each 
job  is  prepared.  In  figure  II. 2. 2.1  we  can  see  that  job  J1  has  three  operations  :  opl,  op2  and  op3. 
Operation  opl  may  be  carried  out  on  machine  mcl  or  mc2  and  so  on..  For  operation  op3  machine 
mc5  may  be  chosen  in  place  of  mc4  and  mc6  taken  together. 

The  search  tree  is  then  developed  using  this  activity-network.  Figure  11.2.2.2  shows  the 
development  of  such  a  search  tree  At  point  'A'  we  were  dealing  with  operation  opl'  and  have  the 
choice  of  either  taking  mcl  or  mc2.  Going  one  step  further  we  have  four  time  periods  to  choose 
from  for  each  machine.  The  schedule  developed  up  until  the  choice  of  the  time  period  is  called  a 
partial  schedule.  We  now  need  some  evaluation  function  by  which  the  nodes  can  be  weighted.  This 
evaluation  function,  as  the  readers  can  see,  is  very  critical  to  the  efficacy  of  the  search  paradigm 
These  evaluations  are  heuristic  in  nature  and  much  research  has  gone  into  the  study  of  these 
evaluation  functions. 

Setting  aside  this  issue  for  a  the  moment  we  proceed  to  develop  our  search  tree.  Assume  we 
decide  to  do  operation  opl  on  machine  mcl  in  time  period  'tl T!..'s  places  us  at  node  'll'  with  a 
choice  between  nodes:  I,J,I<  or  L.  The  hatched  line  in  the  figure  shows  the  path  taken  till  node  K, 
where  time  period  t4'  was  chosen  for  ’mc3\  This  can  be  shown  as  a  Gantt  chart:  figure  11.2  2.3 

After  having  scheduled  Job  Jl  fully,  the  system  chooses  the  next  job  and  perforins  the  same 
process.  If  there  ever  is  a  clash  at  a  machine,  the  system  tries  to  backup  and  choose  another 
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MACHINES 


machine.  If  this  is  not  possible,  the  job  with  higher  priority  gets  scheduled  and  the  other  one  goes 
back  to  the  bag  of  unscheduled  jobs. 

That  was  the  basic  idea  of  scheduling  using  a  search  tree.  We  now  discuss  the  method  of 
choosing  a  node  when  there  are  several  viable  choices.  A  evaluation  function  is  used  to  find  the 
best  choice. 

In  a  constrained  problem  one  can  evaluate  the  nodes  on  the  basis  of  the  extent  to  which  each 
node  satisfies  the  constraints.  If  each  constraint  has  an  utility  then  the  total  utility  at  a  node  i  is 
given  by: 

Utility  =  ►  (Utility  of  constraint  i)  *  (level  of  satisfaction  of  i) 

••■■111 

i 

Such  an  utility  can  be  calculated  for  each  node,  that  is,  for  each  partial  schedule  represented  at 
that  node.  The  above  evaluation  function  does  not  make  an  effort  to  "look  forward".  In  other 
words,  the  evaluation  is  based  upon  the  choices  made  up  until  the  current  node  'n'.  Let  us  call  this 
utility  g(n).  If  the  choice  of  a  node  is  said  to  be  based  on  a  value  called  f(n),  then  the  evaluator  just 
described  is: 

f(n)  =  g(n)  ...  (2) 

The  branch  and  bound  technique's  f(n)  is  different 

f(n)  =  g(n)  +  h(n)  ...  (3] 

where  h(n)  is  a  heuristic  estimate  of  the  total  cost  to  complete.  If  the  h(n)  is  guaranteed  to  be 
a  lower  bound  on  the  actual  cost  to  complete  then  the  search  is  guaranteed  to  terminate  at  a 
optimal  solution.  (Nillson  1971] 

The  subsequent  sections  touch  upon  the  problem  we  are  trying  to  address  in  our  scheduling 
project.  The  domain  is  that  of  scheduling  the  training  activities  of  troops  at  an  army  installation. 
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11.3  The  role  of  Search  in  Scheduling 

We  start  this  section  with  an  explanation  of  the  scheduling  problem  in  a  domain  independent 
fashion.  A  typical  scheduler  can  be  thought  of  as  a  system  which  answers  the  following  questions 

1  Who 

2  Where 

3  What 

4  When 

In  the  job  shop  scheduling  domain  the  ’who’  is  the  job,  ’where’  is  the  machine,  ’what’  is  the 
operation  and  ’when’  signifies  the  scheduled  time.  [Note:  More  dimensions  (e.g.  ’which’  for 
resources)  can  be  added  to  suit  the  domain  in  question] 

Figure  II. 3.1  shows  how  this  kind  of  a  scheme  might  work.  Each  cycle  of  choices  "who  -> 
where  ->  what  ->  when  ..."  is  called  a  scheduling  cycle. 

The  search  tree,  as  shown  in  figure  11.3.1,  is  bound  to  become  very  large.  To  avoid  a 
combinatorial  explosion  we  could  restructure  the  representation  as  in  figure  II. 4.1  Changes  in  search 
or  control  of  constraints  are  all  carried  out  by  heuristic  rules.  This  formalism  allows  us  to  change 
the  performance  of  the  system  by  changing  the  heuristic  rules. 

11.4  Scheduling  Army  Training  Activities 

The  research  presented  in  this  paper  is  all  the  product  of  the  development  of  a  scheduling 
system  for  army  training.  Translating  the  framework  presented  in  section  III.  1 ,  we  have: 


who  = 

battalion 

where  = 

range 

what  = 

training  activity 

when  = 

date 

In  addition  to  this  basic  framework,  we  have  a  large  set  of  constraints  that  need  to  be 
satisfied.  The  constraints  specify  the  conditions  to  be  met  in  the  final  solution.  It  is  possible  that 
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Activity  network 


there  are  several  solutions  to  the  problem.  Our  first  objective  now,  i..  to  find  any  of  the  satisficing 
solutions. 

For  this  domain,  a  activity  network  is  drawn  for  each  battalion.  The  network  is  shown  in 
figure  II. 4.1  The  figure  shows  the  activity  network  of  a  battalions  called  HI’  .  The  activities  to  be 
chosen  from  are  :  al,a2  and  a3.  The  firing  range  is  to  be  chosen  from  among  rl,  r2  and  r3.  The 
search  tree  has  been  reduced  in  size  by  assuming  sequential  scheduling.  The  activity  network  has 
choice  nodes  at  the  beginning  of  each  day. 

Once  an  activity  has  been  chosen  for  a  particular  day,  the  next  step  shall  be  the  choice  of  the 
range  where  the  activity  should  be  carried  out.  The  ranges  available  to  each  activity  is  dictated  by 
the  nature  of  the  activity  and  the  size  of  the  range,  (e.g.  If  a  range  is  small,  it  cannot  support 
weapon  systems  which  require  large  safety  spans.) 

Having  presented  the  basics  of  schedule  generation  using  the  Search  paradigm,  we  conclude 
this  introductory  chapter.  The  following  chapters  start  the  discussion  about  the  role  of  constraints 
in  scheduling. 
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Chapter  DI 


Passive  Use  of  Constraints: 

The  First  Implementation 

111.1  Introduction 

It  is  our  aim  to  develop  a  scheduling  system  that  will  be  able  to  handle  ad-hoc  constraints. 
This  chapter  presents  some  of  the  representations  used  for  schedule  generation  and  discusses  the 
passive  use  of  constraints. 

Constraints  are  said  to  be  passive  when  they  do  not  play  an  active  role  in  guiding  the  search 
process.  The  constraints  are  used  only  after  a  partial  schedule  is  generated.  In  essence  it  is  a  case  of 
the  Generate  and  Test  paradigm. 

111.2  Partial  Schedules 

As  stated  in  section  II.3,  the  scheduling  problem  can  be  solved  by  search  techniques.  The 
product  of  each  scheduling  cycle  is  an  assignment  of  a  battalion  to  a  range  for  a  particular  training 
activity  on  a  particular  day.  This  is  represented  as  a  predicate  called  scheduled.  The  form  of  the 
predicate  is  thus: 

(scheduled  {battalion _ name}  {activity _ name)  {range_no}  { time _ period}) 

Each  such  assignment  is  called  a  schedule  element.  The  complete  schedule  consists  of  several 
such  schedule  elements.  Consider  a  scheduling  cycle  of  the  following  configuration: 
battalions:  {bat_A  bat_B  bat_C} 

activities:  {  act_A  act_B  act_C  } 

ranges:  {  range_A  range_B  range_C  } 
time  periods:  {  1  2  3  4  5  6  7  8  9  10  11  12} 

A  search  tree  is  shown  in  figure:  111.2.1  .  The  hatched  lin  ■;  i  i  the  figure  shows  us  that 
battalion:  bat_A  is  going  to  perform  activity:  act_A  on  range_C  on  day:  8.  In  addition  it  shows 
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that  battalion:  bat_B  will  perform  act_C  on  range_B  on  day:  6. 

The  scheduling  elements  developed  in  the  figure  are: 

(scheduled  bat_A  act_A  range_C  8) 

(scheduled  bat_B  act C  range_B  6) 

By  going  deeper  in  the  search  tree  the  scheduling  elements  start  representing  a  more  detailed 
schedule.  The  constraints  are  used  to  check  the  schedules  prepared  by  the  search  process. 

A  depth  first  search  technique  was  employed.  The  first  implementation  was  built  with  the 
idea  of  using  constraints  in  an  after  the  fact  fashion.  For  successful  completion,  the  schedule 
produced  by  the  system  had  to  satisfy  all  the  constraints.  Every  time  the  path  is  expanded,  it  is 
checked.  There  are  three  outcomes  of  such  a  check.  The  check  function  returns  a  message  to  the 
scheduler  telling  it  the  status  of  the  schedule  generated. 

I  all_salisfied 

This  means  that  all  the  constraints  are  fully  satisfied,  and  that  the  schedule  is  complete. 

£  continue 

This  message  is  passed  back  when  the  current  schedule  is  found  to  be  partial.  When  the 
schedule  is  partial,  all  the  constraints  will  not  have  been  invoked.  However,  those  invoked  will  be 
satisfied.  (Note:  a  constraint  is  invoked  when  it's  premises  are  true.) 

S  failure 

.  As  soon  as  a  violation  occurs,  failure  is  indicated.  The  failure  message  causes  the  scheduler  to 
backtrack  to  the  last  scheduling  decision.  This  action  is  called  chronological  backtracking  and  is 
generally  very  inefficient. 
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The  procedure 

1.0  Form  a  stack  of  constraints 

2.0  Unstack  the  first  constraint  and  test  it  against  the 
current  partial  schedule. 

Add  the  returned  message  to  a  results  list. 

3.0  If  any  one  of  the  results  is  failure  then  fail  and 
start  backtracking  . 

4.0  If  not  end  of  constraints  stack,  go  to  2.0 

5.0  If  any  one  of  the  results  is:  not- applicable  then 

continue  the  search. 

6.0  If  all  results  are  'satisfied'  then  return  the  message: 

’all_satisfied'  and  terminate  the  search. 

III.3  The  constraints 

The  reader  would  have  noticed  the  use  of  message  called  'not-applicable'.  This  signifies  the 
situation  where  a  partial  schedule  cannot  satisfy  all  the  constraints.  Let  us  now  examine  what 
'not-applicable'  means:- 

Each  constraint  has  three  parts: 

(1)  Name  of  the  constraint 

(2)  The  applicability  pattern /patterns 

(3)  The  tests 

When  a  constraint  is  to  be  checked  against  a  schedule,  its  applicability  is  checked  first.  If  it  is 
applicable,  then  the  tests  are  executed.  The  constraint  is  deen  ed  satisfied  if  all  the  tests  return 
'true'. 

The  constraints  are  written  in  a  crude  (first  cut)  constraint  definition  language  called  CDL-1. 
The  CDL  used  in  a  later  implementation  is  more  powerful  than  the  one  presented  in  this  section 
Before  we  go  further,  let  me  set  the  stage  for  CDL-I  and  present  a  few  examples. 


CDL-1  makes  use  of  a  pattern  matching  and  variable  binding  facility.  It’s  patterns  act  directly  /j 

on  the  schedule  elements.  Extending  the  example  problem  presented  in  scenario  (Chapte,  I)  we  ' 

shall  set  up  some  constraints  for  the  problem. 

The  syntax  of  a  typical  constraint  is:  j 

J 

(constraint  (name  -name-  )  , 

(  -pattern-  ) 

(  -tests-  )  ) 

S 

Let  us  now  translate  some  of  the  constraints  into  CDL-I. 

The  constraint  Cls  "A  battalion  can  do  only  one  activity  in  one  time  period”. 

(constraint  (name  Cl) 

(>bat  >act  >range  >day) 

— >  (equal  (sigma  (<bat  >act  >range  <day))  1.0)) 

The  above  constraint  has  the  name  'Cl'  and  has  a  pattern: 

(>bat  >act  >range  >day) 

and  a  test  (for  testing  the  generated  schedule). 

The  program  has  a  stack  of  such  constraints.  It  picks  up  a  constraint  and  tests  it.  The  first 
step  is  to  match  the  pattern  against  a  database.  The  use  of  the  symbol  ’>’  (do  not  view  it  as  a 
greater-than  sign)  means  that  the  attached  word  is  a  variable.  This  variable  can  be  bound  to  any 
value  in  the  process  of  pattern  matching.  For  example,  if  we  match  the  pattern: 

(bat_A  >xl  >yl  >zl) 

with  the  schedule  element  (stored  in  the  data  base): 

(bat_A  act_A  range_A  8) 

then  the  matcher  will  match  bat_A  to  bat_A  ,  xl  to  act_A,  yl  to  range_A  and  so  on. 
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Consequently  the  bindings  will  be  thus: 


xl 

= 

act_  A 

yi 

= 

range  _  A 

zl 

— 

8 

Once  bound,  the  variables  can  be  used  in  the  testing  part  of  the  constraint. 

Now  for  an  extended  example:  let  us  assume  that  there  is  a  partial  schedule  that  looks  like 

this:- 


(  (bat_A 

act 

A 

range  B 

8) 

(bat_B 

act 

B 

range_C 

4) 

(bat_C 

act 

C 

range  A 

6) 

(bat_B 

act 

A 

range  A 

4)  ) 

There  is  a  problem  in  this  schedule.  Battalion:  bat_B  has  been  scheduled  to  do  two  different 
things  on  the  same  day  (i.e.  day:  4). 

The  constraint  Cl  has  to  catch  this.  It  has  in  its  test  a  statement  that  says  :  "for  each 
battalion,  the  day  assigned  to  each  schedule  element  has  to  be  unique  to  that  schedule  element".  In 
other  words,  the  total  number  of  schedule  elements  in  the  database  that  have  the  same  battalion 
name  AND  the  same  day  should  be  unity. 

For  example,  let  us  choose  bat_B.  We  start  at  the  top  with  the  first  schedule  element  for 
bat_B: 

(bat_B  act_B  range_B  4) 

The  constraint  Cl  will  have  the  following  bindings:  act  =  ’act_B’,  range  =  ’range_C’  and 
day  =  4.  It  now  knows  that  for  bat_B  there  should  not  be  any  other  schedule  element  with  day 
=  4.  This  is  regardless  of  the  activity  and  the  range.  In  some  sense,  the  total  number  of  schedule 
elements  that  match: 
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(bat_B  >act  >range  4) 


should  be  unity.  The  summations  is  carried  out  by  th**  function  in  the  C ' I ) I >- 1 

constraint  shown  above.  The  pattern  has  two  variables  >act  and  >  range  in  it.  For  this  reason  it 
will  match  any  element  which  has  the  string  ”bat_B”  in  the  first  pi.'.ce,  anything  in  the  second 
and  third  places  and  ”4”  in  the  fourth  place.  We  can  see  that  the  above  pattern  will  match  the 
partial  schedule  twice.  Consequently  the  test  will  fail. 

Let  us  look  at  the  constraint  Cl’s  code  again.  It  had  a  test  part  with  the  pattern: 

(<bat  >act  >range  <day) 

in  it.  This  pattern  has  two  variables  >act  and  >range.  It  has  a  new  symbol  "<”  .  This 
symbol  means  that  the  value  of  the  variable  should  be  instantiated.  In  other  words  the  the  above 
pattern  gets  converted  to 

(bat_B  >act  >range  4). 

This  is  the  basic  idea  behind  CDL-I’s  pattern  matcher.  We  have  used  this  method  of  binding 
and  instantiation  because  we  later  will  write  constraints  which  are  able  to  write  constraints. 

The  constraint  C2:  "There  shall  be  only  one  battalion  on  a  particular  range  in  a  particular 
time  period." 

(constraint  (name  C2) 

(>bb  >aa  >rr  >dd) 

-->  (equal  (sigma  (>b  >a  <rr  <dd)  ) 

1.0)) 

Constraint  C4:  The  ranges  which  are  suited  to  each  activity: 
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(constraint  (name  C4_one) 

(>bat  act_A  >range  >day) 

— >  (or  (equal  <range  range_A) 

(equal  <range  rangeB))  ) 


(constraint 
— > 


(name  C4_two) 

(>bat  act_B  >range  >day) 
(equal  <range  range_C)) 


CDL-1  is  not  good  for  some  complex  constraints.  A  CDL-II  has  been  developed  which  allows 
for  the  intelligent  use  of  constraints. 

III.4  CDL-I:  Performance  Issues 

The  performance  of  the  CDL-I  based  search  mechanism  was  very  poor.  The  program  took 
several  hours  to  run.  Slightly  bigger  problems  caused  serious  problems  and  was  full  of  backups.  It 
always  seemed  to  be  looking  down  the  wrong  path!  It  has  been  estimated  that  if  this  strategy  is 
used  for  a  full  fledged  problem,  it  may  require  several  months  of  CPI'  time  before  it  can  terminate 
successfully.  So  much  for  the  passive  use  of  constraints. 

The  purpose  of  this  chapter  is  to  give  the  reader  a  feel  for  the  motivations  for  moving 
towards  the  intelligent  use  of  constraints.  The  development  of  such  intelligent  techniques  is  the 
essence  of  this  thesis. 
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Chapter  IV 


Active  Use  of  Constraints: 

-  Some  Intuitive  Ideas 

IV.  I  Introduction 

This  chapter  adopts  a  highly  intuitive  approach  to  the  concept,  of  active  constraint  utilization. 
In  Chapter  III  we  saw  how  the  generate  &  test  method  of  search  fails  to  deliver.  In  this  chapter  we 
show  how  constraints  can  be  used  for  search  pruning.  We  present  a  framework  wherein  constraints 
are  not  hard-wired  into  the  scheduler  but  are  input  via  a  constraint  definition  language  (COL). 
Consequently,  the  constraints  can  be  changed  by  the  user  as  and  when  adjustments  are  required. 
Such  flexibility  is  essential  to  real-world  scheduling  systems. 

The  constraints  and  the  data  are  the  only  domain  dependent  parts  of  the  program.  The 
constraints  are  essential  to  the  operation  of  the  scheduler.  If  there  are  no  Constraints  at  all,  the 
program  will  do  nothing.  We  need  to  tell  it  that  it  is  a  scheduler! 

Consider  the  constraint  shown  below:- 

(Note:  The  CDL  used  here  is  in  plain  English  only  for  the  sake  of  brevity,  a  more  formal 

development  is  presented  in  Chapter  Vj 

[Constraint:  Battalion  #42  shall  perform: 

|l|  300  hrs  of  tank _training 

[2|  50  hrs  of  Dragon _qual 

|3|  50  hrs  of  M16_sustain 

(4)  I  CALFX 

[5]  .... 


Given  the  above  constraint,  the  system  may  start  scheduling  all  the  activities  on  the  same 

day  and  maybe  on  the  same  range.  More  constraints  need  to  be  added  to  avoid  this  problem: 

[Constraint:  There  shall  be  only  one  activity  per 
battalion  per  day] 
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(Constraint:  There  shall  be  only  one  battalion  per 
range  per  day] 

These  two  constraints  will  avoid  clashes  and  ensure  safety. 

Having  given  the  reader  a  flavor  of  what  we  mean  by  constraints;  we  now  embark  upon  a 
series  of  examples  to  illustrate  the  operations  on  the  constraints.  The  basic  operations  are: 

( 1]  Instantiation 
[2j  Generation 

[3]  Posting 

[4]  Propagation 

[5]  Relaxation  (not  examined  in  this  paper) 

[6]  Satisfaction 

IV. 2  Instantiation 

A  constraint  is  said  to  be  instantiated  when  any  of  the  variables  within  the  CDL  are  bound  to 
objects  in  the  domain.  If  there  is  a  constraint  which  says  that  every  battalion  shall  qualify  on  the 
M-16:- 

(  Constraint:  For  all  values  of  V  .where  'x'  is  a 
battalion,  that  ’x’  shall  perform  50 
hours  of  M-16  qualification] 

The  variable  'x'  is  then  free  to  be  bound  to  any  battalion  in  the  database.  Once  this  generic 
constraint  is  bound,  it  is  posted  against  the  corresponding  object. 

IV. 3  Generation  &  Posting 

Constraint  posting  can  be  initiated  cither  by  a  pre-specified  global  constraint  or  by  a 
generated  one. 

(1)  A  pre-specified  global  constraint  is  one  that  is  always 
true  (at  least  they  are  intended  to  be  so). 

Here's  an  cxample:- 

[  Constraint:  There  shall  be  no  training  on  Sunday) 
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(2)  A  conditional  constraint  is  generated  in  the  process  of 
solution: 

(Constraint:  IK  tank-training  is  scheduled  for  rangel6 

THEN  It  is  not  safe  to  train  on  the 

adjoining  ranges:  rangel5  and  rangel7.j 

>  Such  a  constraint  remains  passive  until  its  pre-conditions  are  met. 

Preference  constraints  are  also  posted  against  objects  in  the  database.  One  may  prefer  to  do  a 
FTX  type  activity  during  the  non-winter  months  or  one  may  prefer  not  to  schedule  Mlfi_qual  on 
rangel2.  These  constraints  are  posted  at  the  appropriate  location  on  the  activity  network. 

IV. 4  Propagation 

The  first  significant  use  of  constraint  posting  and  propagation  in  planning  was  done  by 
Stallman  &  Sussman  (1977).  Later,  Mark  Stefik  of  Stanford  built  an  excellent  system  called 
MOLC5EN  (Stefik  1981).  His  work  has  shown  us  how  symbolic  constraints,  through  the  process  of 
posting  and  propagation  can  help  in  complex  domains. 

There  are  several  types  of  constraint  propagation  relevant  to  our  work. 

a)  Forward  Propagation 

After  a  constraint  is  posted,  it  may  be  propagated.  Consider  a  constraint  which  requires  us  to 

perform  an  activity  ’act6’  for  3  successive  days: 

(Constraint:  IF  ’act6’is  scheduled  on  a  day  'x’ 

THEN  ’act6’  shall  be  scheduled  on  days  x  +  1 
and  x  +  2  also] 

Figure  IV. 4.1  shows  us  how  such  a  change  might  occur.  As  soon  as  ’act6’  was  scheduled  on  day  11, 
the  above  constraint  was  activated  and  it  was  propagated  to  day  12  &  day  13.  The  next  scheduling 
cycle  will  start  on  day  14. 

b)  Cross  Propagation 

In  section  IV. 1  we  introduced  a  constraint  which  required  that  only  one  battalion  can  be  on  a 
range  at  a  time.  Figure  IV. 4. 2  shows  us  how  such  a  constraint  is  propagated  from  one  job  to 
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another.  If  the  Armor  Battalion  10  is  scheduled  on  range  ’Rl’  on  a  particular  day,  the  constraint  is 
propagated  to  other  battalions  and  the  range  is  deactivated. 

Another  kind  of  cross  propagation  is  diagonal  in  nature.  Consider  the  following  preference 
constraint: 

[Constraint:  IF  tank _ training  was  scheduled  on  range 

V  on  day  'y' 

THEN  It  is  preferred  to  reschedule 
tank_training  on  range  V  on 
day  ('y’  +  1).  ] 

This  constraint  captures  the  fact  that  the  setup  costs  of  targets  on  a  range  for  a  particular  activity 
should  be  translated  to  the  next  activity  scheduled  on  that  range.  Figure  IV. 4. 3  shows  how  this 
may  be  done  in  a  two  battalion  situation.  As  soon  as  tank _training  was  chosen  for  Batl  at  range 
R3  on  DAY116  it  propagates  'diagonally'  across  to  the  other  battalion  and  increases  the  preference 
level  of  R3  for  tank-training.  In  other  words,  if  tank_training  is  chosen  for  Bat2  on  dayl!7,  then 
range  R3  would  be  preferred. 
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c)  Backward  Propagation 


We  shall  examine  two  forms  of  backward  propagation,  the  first  type  is  used  for  due-date 
constraints. 

(  Constraint:Duedatel  :  Armor  Battalion  10  should  complete 
all  training  by  Oct  15] 

Backward  propagation  (i.e.  backwards  from  the  due-date)  is  to  be  used  only  if  there  was  a  failure  in 
the  forward  propagation.  This  mode  of  propagation  is  similar  to  forward  propagation,  but  in 
reverse. 

The  second  type  of  backward  propagation  is  very  interesting.  In  the  domain  of  troops 
training,  one  has  to  design  well  balanced  training  programs.  It  is  required  that  certain  proficiency 
levels  are  maintained  among  the  troops  in  different  weapon  systems.  In  keeping  with  this,  a  cyclical 
constraint  is  imposed.  Such  a  constraint  requires  that  certain  training  activities  should  be  carried 
out  at  regular  intervals,  throughout  the  year.  This  ensures  that  the  troops  neither  train  on  one 
weapon  system  all  at  once,  nor  have  long  time  gaps  between  training  sessions  of  a  particular  type. 
Figure  IV. 4.-1  [Source:  Eilts,  Wright,  Houck  1984]  shows  a  plot  of  proficiency  levels  vs  time.  In  order 
to  maintain  a  steady  level  of  proficiency  in  any  weapon  system,  troops  should  be  trained  on  that 
system  periodically. 

[Constraint.  Cyclical  :  IF  a  battalion  is  scheduled  for 
tank_training  on  some  day  'd' 

THEN  it  should  not  be  rescheduled  for 
tank-training  over  the  next  30  days 
after 'd' 

AND  it  should  be  rescheduled  in  less 
than  60  days  after ’d ’) 

Assume  that  a  typical  tank-training  session  was  5  days  long  and  there  were  to  be  five  such 
sessions  in  a  year.  Figure  IV.4.5  shows  this  constraint  as  a  bunch  of  blocks  and  springs.  The  blocks 
signify  the  training  sessions  and  the  springs  allow  us  to  incorporate  some  slack.  The  length  of  a 
block  represents  the  time  period  of  the  corresponding  session  and  the  length  of  the  spring  between 
two  blocks  is  the  time  gap  between  sessions.  The  level  of  compression  of  the  springs  is  a  measure  of 
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Curves  For  Training  Source:  E  ilts^  U/gifaur  E-  Houck  /clS4) 
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deviation  from  the  constraint’s  tenets. 


Once  the  scheduling  starts,  a  constraint  like  the  one  in  figure  IV. 4. 5  lurks  about  the  vicinity 
of  the  planning  networks  and  waits  to  be  invoked.  This  constraint  will  come  into  effect  only  after 
the  first  training  session  is  actually  scheduled.  As  the  scheduler  advances  along  the  planning 
network  the  cyclical  constraint's  block&spring  system  gets  pushed  back.  As  the  end  of  year 
approaches  the  block&spring  system  gets  pushed  up  the  'utility  mountain’  (figure  IV. 4.6).  As  the 
scheduling  front  moves  forward  without  scheduling  tank-training  it  gets  tougher  and  tougher  to 
push  back  the  block&spring  system.  This  is  corrected  by  a  backwardly  propagated  constraint.  As 
shown  in  the  figure,  constraint  'A',  propagates  backwards  and  increases  the  preference  level  of 
tank-training  for  the  next  day. 

IV. 5  A  classification  for  constraints. 

Constraints  can  be  classified  on  the  basis  of  the  effects  that  they  have  on  the  schedule 
elements  and  their  variables.  A  constraint  that  uses  data  of  several  schedule  elements  is  called 
multi-element  in  nature.  The  multiplicity  of  variables  is  the  other  dimension. 

Single  Multi 

Element  Element 


Single 

variable  SV/SE  SV/ME 
Multi 

variable  MV/SE  MV/ME 


The  most  complex  constraint  is  the  MV/ME  (Multi-variable/multi-element)  type.  It  involves 
several  scheduling  elements  and  places  constraints  on  a  more  than  one  variable.  By  using  constraint 
generation,  it  is  possible  to  convert  complex  constraints  into  simpler  cases.  The  simplest  case  is  the 
SV/SE  case.  The  methods  used  to  convert  a  constraint  from  one  class  to  another  is  presented  in 
the  next  chapter. 
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Chapter  V 


Active  Use  of  Constraints 

-  The  Second  Implementation 


V.O  Introduction 

Having  given  the  reader  a  intuitive  feel  of  how  constraints  may  be  used  for  scheduling.  We 
now  proceed  to  understanding  the  workings  of  the  second  implementation.  The  second 
implementation  uses  constraints  through  the  powerful  mechanisms  of  constraint  generation,  posting 
&  propagation.  Unlike  the  passive  case,  this  technique  tends  to  be  lot  more  efficient.  Large  problems 
could  be  solved  in  reasonable  (few  hours)  time. 

A  new  and  improved  constraint  definition  language  called  C'DL-11  was  used  CDL-II  is  built 
wholly  in  a  production  system  (similar  to  YAPS)  called  IMST.  (Refer  Appendix  A) 

V.l  The  representation 

The  basic  task  performed  by  the  scheduling  algorithm  presented  in  this  thesis  is  similar  to 
that  of  linear  programming. 

The  problem  is  set  up  as  a  large  group  of  variables.  Each  variable  has  a  corresponding  value 
set.  These  value  sets  are  lists  of  atoms.  Through  a  search  process  one  of  the  atoms  is  chosrn  from 
the  value  set.  This  is  done  for  each  variable.  When  all  the  variables  are  assigned  to  unary  (single 
valued)  sets,  the  schedule  is  deemed  to  be  complete. 

In  Chapter  IV  we  mentioned  that  a  schedule  consists  of  several  schedule  elements.  In  the 
program  the  schedule  elements  have  variables  in  them.  For  example,  the  schedule  element  (bat_A 
act_C  rangeA  9)  says  that  battalion  bat_A  will  perform  activity  act__C  on  range  A  on  day: 
9.  This  schedule  element  will  now  be  represented  as: 

(bat_A  actl  rangel  dayl) 

where  actl,  rangel  and  dayl  are  variables  that  are  attached  to  battalion:  bat  A.  The 
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corresponding  variable  bindings  are:  J 

i 

A 

actl  =  act_A  1 

range 1  =  range_A 

dayl  =  9 

Each  schedule  element  represents  one  schedule  instance.  That  is,  it  represents  a  unique  set  of 
variable  assignments.  These  scheduling  elements  are  stored  in  a  data  base.  The  element  can  be  put 

*S 

into  the  data  base  by  using  the  assert  function. 

For  a  better  understandv <g  •:/  the  concepts  of  assertional  databases  and  of  pattern  direct td 
inferencing.  the  reader  is  urged  to  read  Chapters  1  &  S  of  Appendix  A 

V.2  The  constraint  Definition  language  CDL-II 

CDL-II  is  based  on  the  concepts  of  fundamental  set  theory.  Each  schedule  element  has 
variables  in  it.  For  example  a  schedule  element: 

(bat_A  act0019  range0019  day0019) 

has  three  variables  act0019,  range0019  and  day0019.  These  variables  have  associated  sets  of  '< 
values  from  which  one  value  has  to  be  chosen. 

The  constraints  are  used  to  trim  and  focus  these  value  sets  and  thus  help  in  pruning  the 

- 

search  space.  The  physical  action  of  the  constraints  on  these  sets  are  set  theoretic  in  nature: 

-  Intersection 

-  Subtraction 

-  Union 

-  Restriction 

These  basic  operations  allow  us  to  manipulate  value  sets  in  various  ways.  The  first  three 
operators  are  obvious.  Restrict  is  used  to  filter  a  ualue  set  based  on  a  particular  predicates  or  some 
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testing  function.  For  example,  if  one  wants  to  restrict  a  list  of  the  first  10  integers  to  only  those 
that  are  greater  than  6:- 


(restrict 

) 


*(1  2  3  4  5  6  7  8  9  10) 
•(gt  $$$  6) 


The  $$$  symbol  signifies  the  list  which  has  to  undergo  restriction.  The  result  of  the  above 
restriction  will  be  (7  8  9  10). 


The  other  functions  available  in  CDL-1I  are: 

(set  _  value  -var-  -list-  ) 

this  sets  the  value  of  a  variable  to  a  particular  list. 

(get _ value  -var-  ) 

retrieves  the  latest  value  of  a  variable. 

(selected?  -var-  ) 

checks  to  see  if  all  the  variables  in  the  supplied  list  are 
selected  variables.  \  selected  variable  is  one  which  has  a  value  set 
with  only  one  value  in  it. 


With  these  functions  it  is  possible  to  write  constraints.  Once  again,  picking  up  the  example 
problem  from  part  D  of  chapter  I. 

(a)  Constraint:  Cl 

In  English: 

”  A  battalion  can  do  only  one  activity  in  one  time  period 
In  CDL-l: 
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JUk 


(constraint  Cl  (>bat  >act  >range  >day) 


test  (selected?  <day) 

— >  (constraint  Cl_aux  (<bat  >al  >rl  >dl) 

test  (not  (equal  (quote  <day)  dl)) 

— >  (set_value  dl 

(subtract  (get_value  dl) 

(getvalue  (quote  <day))) 

))) 

Here  is  a  good  example  of  constraint  generation.  The  constraint  Cl  produces  a  secondary 
constraint  called  Cl_aux.  Once  generated,  the  Cl_aux  performs  SV/SE  (refer  Section  IV'. 5) 
propagation.  Note  that  Cl  is  SV/ME  constraint  and  it  gets  converted  into  the  SV/SE  case. 

Let  us  complement  this  with  an  example.  If  we  have  a  partial  schedule: 


1 : 

(assert  bat_A 

actOOl 

rangeOOl 

dayOOl) 

2: 

(assert  bat_A 

act002 

range 002 

day002) 

3: 

(assert  bat  A 

act003 

range003 

day 003) 

4: 

(set_value  ’actOOl  ’(al)  ) 

B: 

(set_value  ’act002 

‘(al)  ) 

6: 

(setvalue  ’act003 

’(al)  ) 

Figure : 

V.2.1 

This  way  of  setting  up  the  data  explicitly  lists  down  the  number  of  scheduling  elements 
required.  Notice  that  the  scheduling  elements  are  added  to  the  database  via  assertions  which 
consist  of  a  battalion  name  followed  by  three  variables.  The  database  produced  will  be: 
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(  bat_A  actOOl  rangeOOl 
C  bat_A  act002  range002 
(  bat_A  act003  range003 


dayOOl) 

day002) 

day003) 


The  corresponding  variable  bindings: 


Variable 

Binding 

actOOl 

(al) 

act002 

(al) 

act003 

(al) 

When  the  constraint  Cl  is  executed  it  will  generate  the  following  new  constraint. 

(constraint  Cl_aux  (bat_A  >al  >rl  >dl) 

test  (not  (equal  ’dayOOl  dl)> 


— >  (setvalue  dl 

(subtract  (get_value  dl) 

(getvalue  ’dayOOl)))  ) 


The  other  two  constraints  will  have  day002  &  day003  in  place  of  dayOOl  above.  Cl_aux  can 
match  any  element  of  battalion  ’bat_A'  except  the  one  with  dayOOl  in  it.  It  will  then  proceed  to 
subtract  the  value  from  the  current  element's  day  set  (bound  to  dl,  above).  For  example  if  dayOOl 
was  set  to  (8),  then  it  would  be  deemed  tclected  and  will  make  constraint  Cl  generate  Cl_aux.  In 
turn  Cl_aux  will  subtract  out  the  value  (8)  from  the  value  sets  of  all  other  day  elments  of  that 
battalion. 

(b)  Constraint:  Ct 
In  English: 
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There  shall  be  only  one  battalion  on  a  particular  range  in  a  particular  time  period. 


In  CDL-II: 


(constraint  C2  (>bat  >act  >range  >day) 
test  (selected?  <range  <day) 

— >  (constraint  C2_one  (>b2  >a2  >r2  >d2) 
test  (not  (equal  a2  (quote  <act))) 

;  make  sure  its  not  the  same  one! 

(equal  (get_value  r2)  (quote  <(get_value  range))) 

— >  (set_value  d2 

(subtract  (getvalue  d2) 

(quote  <(get_value  day))))) 

;  the  second  constraint  generated  by  C2 

(constraint  C2_two  (>b3  >a3  >r3  >d3) 

test  (not  (equal  a3  (quote  <act))) 

(equal  (getvalue  d3) 

(quote  <(get_value  day))) 

— >  (set_value  r3 

(subtract  (get_value  r3) 

(quote  <(get_value  range)))))  ) 


(  The  use  of  '!'  is  equivalent  of  the  use  of  the  comma  for  the  backquote  macro.) 

Constraint  C2  looks  for  any  schedule  element  that  has  both  the  range  &  the  clay  selected. 
Once  this  is  done  it  generates  two  new  constraints  C2_one  and  C2_two.  For  example,  if  range: 
range_B  is  reserved  for  day  5,  then  C2_one  will  go  around  looking  for  any  battalion  that  is 
scheduled  for  range:  range_B,  it  will  then  remove  day:  5  from  the  value  set  of  that  schedule 
element.  C2_two  does  just  the  opposite. 

Constraint  C2  was  multi-variable/multi-element  whereas  C2_one  and  C2_two  are  SV/ME  . 
Extending  the  data  set  in  figure  V.2.1  we  have: 
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7: 

(assert  bat 

B  act004  range004 

day004) 

8: 

(setvalue 

’act004  ’(act_A)) 

9: 

(set_value 

*range004  ’(range_A)) 

10: 

(set_value 

’day004  ’(6)) 

11 : 

(assert  bat 

_B  actOOS  range005 

dayOOB) 

12: 

(set_value 

’dayOOS  1 (1  2  3  4  5  6 

7  8  9  10  11  12)  ) 

13: 

(set  value 

’rangeOOB  '(range_A>) 

Figure:  V.2.2 


The  statements  7,9  &  10  will  cause  constraint  C2  to  generate  C2_one  and  C2_two,  as  the 
range  &  day  are  both  selected  for  battalion  bal_B,  the  new  constraints  that  are  generated  are: 

(constraint  C2_one  (>b2  >a2  >r2  >d2) 

test  (not  (equal  a2  ’act004)) 

(equal  (getvalue  r2  * (rangeA))) 

-->  (set_value  d2 

(subtract  (get_ralue  d2)  '(5)) 

)) 


(constraint  C2_tvo  (>b3  >a3  >r3  >d3) 

test  (not  (equal  a3  ’act004)) 

(equal  (get_value  d3)  '(6)) 

— >  (setvalue  r3  (subtract  (get_ralue  r3) 

’ (range_one))) 


) 


Let  us  go  through  the  process  by  which  C2_two  >s  tested  against  the  partial  schedule 
presented  in  figures  V.2.1  and  V.2.2,  When  C2__two  comes  to  expression  11.  The  bindings  will  be  : 

b2  =  bat  A 
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a2  =  act005 
r2  —  rangeOOB 
d2  =  day005 

The  first  test  is:(not  (equal  ’act005  ’act004)),  the  second  one  is:  (equal 

(getvalue  ’rangeOOB)  ’  (range_A))  .  Both  tests  are  true.  The  final  part  expands  to: 

(set_value  'dayOOB 

(subtract  '(12345678910)  ’(5))  ) 

The  value  of  day005  is  now  set  to  a  new  value  set  without  the  value  (5).  The  search  proceeds 
with  this  new  restricted  value  set. 

(c)Constralnt  C3 

In  English: 

If  any  battalion  is  scheduled  for  activity  act_B  then  it  should  not  be  schtduled  for  anything  in 
the  immediately  next  period. 

In  CDL-II: 

(constraint  C3  (>bat  >act  >ran  >dd) 

test  (equal  (get_value  <act)  *(act_B)) 

(selected?  <dd) 

— >  (constraint  C3_aux  (<bat  >actl  >ranl  >ddd) 

test  (not  (equal  rani)  (quote  <ran)) 

— >  (setvalue  ddd 

(subtract  (get_value  ddd) 

(list  (+  1  (car  (get_value  (quote  <dd))))) 

)))) 


58 


(d)  Constraint  C4 


In  English: 

Activity  act_A  can  be  carried  out  on  ranges  range_A  and  range _B  only 

In  CDL-II: 

(constraint  C4  (>bl  >al  >rl  >dl) 

test  (equal  (get_value  <al)  * (activity_A)) 

— >  (set_value  <rl  * (rangeA  range_B))) 

Note  that  C4  is  a  SV/SE  constraint  and  is  directly  applicable. 

(e)  Constraint  C5 

These  const  laints  are  expressed  directly  as  assertions  and  set_value  calls.  Figures  V.2.1  & 
V.2.2  show  us  how  this  may  be  done.  This  is  probably  one  of  the  limitations  of  CDL-II.  It  requires 
the  user  to  specify  the  actual  number  of  schedule  elements.  Each  assertion  produces  one  schedule 
element  with  three  variables,  the  constraints  could  be  used  to  develop  the  elements  but  it  would 
require  some  kludgery. 

(f)  Constraint:  C8 

The  cyclic  constraint  produces  a  constraint  network  which  allows  for  backward  propagation. 

In  English: 

There  is  a  cyclic  constraint  on  the  activity  called  act_A.  This  means  that  a  battalion  should 
perform  act_A  at  regular  intervals.  If  the  first  scheduled  date  is  x,  then  the  next  date  should  be 
after  x+2  but  before  z+4- 

The  constraint  is  clearly  MV/ME  in  nature.  It  should  allow  for  both  backwards  and  forward 
propagation,  as  discussed  in  section  IV. 4  .  Being  a  MV/ME  case  we  will  have  to  reduce  it  to  a 
SV/ME  case  by  using  the  constraint  generation  technique  we  have  been  using  till  now.  To  avoid 


excessive  kludgery  it  was  decided  to  present  only  the  SV/Mk.  case  (after  generation  is  done). 


The  constraint  C'fi  is  to  be  exposed  on  aet_A,  there  are  three  occurrences  of  aet_A  (figure 
V.2.1).  From  the  figure  we  see  that  the  three  variables  dayOOl,  day002  &  day003  are  to  be 
governed  by  the  cyclie  constraint.  Assuming  that  there  is  a  function  called  create_cycle  which 
produces  the  following  constraint,  we  have: 

(constraint  c6_one  (bat_A  actOOl  rangeOOl  dayOOl) 

;  being  specific  to  battalion_one 
;  could  be  done  automatically 


(set_value  'day003 

(restrict  (get_value  *day003) 

■(and  (ge  $$$  (+  (get_min_value  ’day002)  2)) 

(le  $$$  (+  (getmaxvalue  ’day002)  4))))) 

(setvalue  ’day002 

(restrict  (getvalue  ’day002) 

’(and  (ge  $$$  (+  (getminvalue  ’dayOOl)  2)) 

(le  $$$  (♦  (get_max_value  ’dayOOl)  4)) 

(le  $$$  (-  (getmaxvalue  ’day003)  2)) 

(ge  $$$  (-  (get_min_value  ’day003)  4))))) 

(set_value  'dayOOl 

(restrict  (getvalue  ’dayOOl) 

'(and  (le  $$$  (-  (get_max_value  ’day002)  2)) 

(ge  $$$  (-  (get_rain_value  ’day002)  4))))) 

) 


The  functions  get  max  value  and  get  min  val ue  get  the  maximum  and  minimum  value 
of  a  specified  variable.  The  form  of  the  constraint  sets  up  a  constraint  network  (Sussman  G.J.,  G.L. 
Steele  1980).  This  network  deals  with  value  sets  and  has  to  maintain  consistent  propagation.  As  the 
values  are  numeric,  propagation  is  simple  and  definitive. 

Let  us  take  up  an  example  at  this  point.  Extending  the  example  in  figure  V.2.1  we  have: 
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14:  (set  'totalperiod  1 (1  2  3  4  5  6  7  8  9  10  11  12)) 
16:  (set  'earlier  ’(1  234  6)) 

16:  (set  'later  '(8  9  10  11  12)) 

17:  (setvalue  'dayOOl  later) 

18:  (setvalue  'day002  total_period) 

19:  (set_value  'day003  total_period) 


Let  us  now  walk  through  the  propagation.  The  initial  value  sets  are  as  below 


dayOOl:  (8  9  10  11) 

day002:  (1  2  3  4  6  6  7  8  9  10  11  12) 

day003:  (1  2  3  4  6  6  7  8  9  10  11  12) 


When  C6_one  executes,  the  first  setvalue  expands  to: 


(setvalue  ’day003 

(restrict  ’ (1  2  3  4  6  6  7  8  9  10  11  12) 
'(and  (ge  $$$  (♦  1  2)) 

(le  $$$  (+  12  4))  ))) 


The  restriction  causes  the  value  set  to  shrink: 

day003:  (3  4  6  6  7  8  9  10  1  12) 


When  the  second  part  expands,  we  get: 
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(setvalue  ’day002  (restrict  1 (1  2  3  4  6  6  7  8  9  10  1 1  12) 


' (and  (ge  $$$  10) 

(le  $$$  16) 

(le  $$$  10) 

(ge  $$$  (-  3  4))) 

)) 


This  will  return: 

day002 :  (10) 

The  next  times  C6_one  is  called  we  get: 

dayOOl :  (8) 

day 003 :  (12) 

This  is  really  how  constraint  propagation  alone  could  be  used  to  come  up  with  answers. 
Things  do  not  always  work  out  this  way.  Generally  constraints  reduce  the  value-sets  to  some 
smaller  sets  which  then  require  search  techniques.  This  is  the  topic  of  the  next  section. 
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V.3  The  Algorithm 

The  underlying  algorithm  is  that  of  search.  The  process  of  search  consists  of  propagation- 
search-propagation  cycles  which  terminates  when  all  the  variables  have  reached  selected  status. 


The  Algorithm: 


1  Load  data 

3  Load  Constraints 

3  Carry  out  all  the  propagation  possible. 

Unless  the  propagation  returns  an  error  , 
continue  propagation 

IF  a  failure  Is  reached 

THEN  backup  and  retract  all 
the  generated  constraints. 

IF  the  backup  returns  failure, 

THEN  announce  schedule  failure  and  stop. 

4  After  all  propagation,  choose  the  most  constrained 

variable, l.e.  the  variable  with  the  smallest  value-set 
other  than  unary. 

IF  no  such  variable  exists, 

THEN  announce  success  and  stop. 

5  Expand  (branch  further  down  the  tree) 

0  Go  to  step  3 


Figure  V.3.1 
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There  are  two  ways  that  the  algorithm  terminates: 


(1)  success 

Success  is  reached  when  all  the  variables  have  unary  value-scls.  This  condition  is  detected  in 
step!  in  figure:  V.3.1  .  A  function  called  get _  most _constralnted_ variable  searches  from 
among  the  variables  which  have  yet  to  be  assigned.  It  returns  that  variable  which  has  the  smallest 
value  get  other  than  unary.  This  is  done  to  reduce  the  branching  factor. 

2)  failure 

A  total  failure  occurs  when  the  backup  (step  3)  reaches  the  bottom  of  the  scheduling  stack. 
Currently  the  backup  is  chronological  in  nature.  This  is  because  non-chronological  or  dependency 
directed  backup  is  not  easily  determined  (Stallman,  R  &  G.J.  Sussman  1977).  These  ideas  will  be 
developed  later  in  this  chapter. 

V.3.2  Contexts  and  their  Tracking 

Every  time  the  scheduler  passes  through  the  propagatc-branch  cycle,  it  produces  a  new 
context.  The  new  valueg  sett  that  are  assigned  to  a  variable  in  each  propagation  step  are  all 
context  dependent.  Further,  in  order  ot  help  backtracking  the  program  stores  a  history  of  the 
value  eels  for  each  variable.  In  this  way,  the  retraction  of  a  decision  is  done  by  just  undoing  all  the 
effects  of  the  corresponding  context.  Contexts  are  represented  by  the  symbol  cycle.  The 
progression  of  Contexts  is  represented  by  numerically  increasing  the  cycle  number:  cyclel 
cycle2  cycle3 . 

We  will  now  go  through  an  example  which  shows  how  new  contexts  are  created  and  how  they 
are  used.  Before  we  go  further,  lets  look  at  the  functions  set_value  and  get_value  once  again 
and  see  what  they  really  do.  The  value  of  a  variable  is  actually  stored  as  a  push  down  stack.  The 
■«t_value  pushes  the  new  value  onto  the  stack  along  with  the  value  of  the  current  context.  The 
get_valu«  looks  up  the  top  of  the  stack  and  hence  returns  the  latest  value. 

Consider  a  new  example: 
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1.  (assert  bat_A  actl  rangel  dayl) 

2:  (set_value  ’actl  *(act_A)) 

3:  (set_value  'dayl  ’(12346  6)) 

4:  (set_value  'rangel  * (range_A  range_B  rangeC)) 

6:  (assert  bat_A  act2  range2  day2) 

6:  (set_ralue  ’act2  *(act_A)) 

7:  (setvalue  'range2  ’(rangeA)) 

8:  (set_value  ’day2  '(6)) 

9:  (assert  bat_B  act3  range3  day3) 

10:  (set_value  ’act3  ’(act_C)) 

11:  (setvalue  ’range3  ‘ (rangeA  rangeB  rangeC  )) 

12:  (set_value  ’day3  '(123466)) 


Figure:  V.3.2 


The  above  data  assignments  will  translate  into  the  variable  assignments  3s  shown  in  figure 
V.3.3  .  Assuming  that  the  current  cycle  number  is  cycleO,  we  have: 
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Variable 

actl 

(  (cycleO 

dayl 

(  (cycleO 

range  1 

(  (cycleO 

act2 

(  (cycleO 

day2 

(  (cycleO 

range2 

(  (cycleO 

act3 

(  (cycleO 

range3 

(  (cycleO 

day  3 

(  (cycleO 

Figure:  V.3.3 


Value 


(act_A) )  ) 

(1  2  3  4  6  6))) 

(range_A  range_B  range_C) ) 

CactA))  ) 

(6))  ) 

(rangeA))  ) 

(act_C) )  ) 

(range_A  range_B  range_C)) 
(123466))) 


) 


) 


Note  how  the  cycle  number  is  stored  along  with  the  value-sets.  We  are  now  ready  to  start 
applying  the  constraints.  Using  the  same  constraints  as  in  chapter  I  (except  constraint:  C7)  we  get 
the  the  following  new  values.  These  values  are  put  in  on  the  top  of  the  stacks  of  the  corresponding 
variables: 


New  value  added 

Constraint 

Variable 

to  the  stack 

name 

range  1 

(cycleO  (range_A  rangeB)) 

C4_one 

range3 

(cycleO  (rangeB)) 

C4_three 

dayl 

(cycleO  (1234  6)) 

Cl 

Note  that  during  propagation  the  cycle  number  does  not  change. 


In  the  current 


implementation  the  constraint  numbers  are  not  stored  along  with  the  propagated  lists.  If  this 
practice  were  adopted,  it  could  help  in  performing  dependency  directed  backtracking. 

Once  all  the  propagation  is  complete,  the  program  looks  for  the  most  constrained  variable. 
This  variable,  by  definition,  is  one  whose  latest  value-set  has  the  minimum  number  of  values.  The 
k  minimum  number  is  however  has  to  be  greater  than  unity. 

The  variable  ’rangel’  is  the  most  constrained.  The  branches  that  are  produced  are:  range  A 
and  range__B.  These  two  values  constitute  two  different  choices  and  are  hence  attached  to  new 
contexts.  This  is  performed  in  two  steps. 

(setvalue  'rangel  '(cyclel  (rangeJB))  ) 

(setvalue  'rangel  • (cycle2  (rangeA))  ) 

The  stack  for  rangel  now  looks  like  this: 


variable:  rangel 

(cycle2  (range_A) ) 

(cyclel  (range_B)) 

(cycleO  (range_A  range_B)) 

(cycleO  (range_A  rangeB  range_C>) 


Figure:  V.3.4 


The  program  attempts  propagation  once  again.  The  latest  context  being  cycle2.  No 
effective  propagation  occurs.  NOTE  that  we  had  dropped  constraint  C7  from  the  current 
constraint  set.  We  have  dropped  C7  only  momentarily  and  will  reintroduce  it  later. 

Once  again,  the  most  constrained  variable  is  chosen,  this  time  it  is  dayl  with  the  value  set  (1 
2  3  4  6).  The  stack  for  dayl  looks  like  this: 
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variable:  dayl 


(cycle7  (1)) 

(cycle6  (2)) 

(cycle5  (3)) 

(cycle4  (4)) 

(cycle3  (6)) 

(cycleO  (1234  6)) 
(cycleO  (1  2345  6)) 


Figure:  V.3.6 
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After  the  branching  shown  above,  propagation  is  attempted.  Once  again,  propagation  does 
not  occur.  We  enter  the  next  branching  stage  by  choosing  day3. 


variable:  day3 


(cyclel3  (1)) 

(cyclel2  (2)) 

(cyclell  (3)) 

(cyclelO  (4)) 

(cycle9  (5)) 

(cycles  (6)) 

(cycleO  (1  2345  6)) 


Figure:  V.3.6 


Once  again  no  effective  propagation  occurs.  We  now  look  at  a  listing  of  all  the  variables  and 
their  values.  The  value  of  a  variable,  as  returned  by  the  function  get_value  is  it’s  latest  value 
(top  of  the  stack)  regardless  of  the  associated  cycle  number. 


Variable 

name 

(get_value  -var-) 

actl 

(cycleO 

(act  A)) 

dayl 

(cycle7 

(1» 

range  1 

(cycle2 

(rangeA)) 

act  2 

(cycleO 

(act  A)) 

day  2 

(cycleO 

(6)) 

range 2 

(cycleO 

(rangeA)) 

act3 

(cycleO 

(act_C)) 

range3 

(cycleO 

(range  B)) 

day  3 

(cyclelS 

i  (1>> 

Figure:  V.3.6 


As  all  (h*-  variables  are  unary,  the  program  would  announce  success  and  stop  (after 
propagation)  If  however  a  contradiction  was  reached  during  propagation  backup  would  be 
initiated 

Let  us  reflect  on  the  •  •-  for  a  moment  Compared  to  the  first  implementation,  this 

program  terminated  very  quickly  tty  judiciously  using  the  constraints,  backtracking  was  reduced. 
Using  constraints  throuah  mechanisms  like  generation, posting  and  propagation,  search  programs 


have  been  found  to  reduce  bac  k  tracking  dramatically  (Stefik  M.  1980). 


V.4  Backtracking 

To  illustrate  backtracking  we  now  introduce  the  constraint  C7  into  the  example  we  have 
been  working  on.  07  is  a  safety  constraint  that  says  ”  doing  activity:  act_.\  on  range__A  on  a 
particular  day,  wilt  cause  range _B  to  be  unusable  on  that  day."  By  glancing  at  the  final  results  as 
►  shown  in  figure  V.3.6  one  notices  that  C7  is  violated.  On  day  ’1'  battalion:  bat_A  will  be 

performing  aet_A  on  range_A,  however  range_B  will  be  occupied  by  bat_B  on  the  same  day. 
This  causes  an  error  when  constraint  C7  is  enforced. 

There  are  several  ways  of  backtracking  at  this  point: 

1:  Change  day 3  to  (2) 

or  2:  Change  dayl  to  (2) 

or  3:  Change  rangel  to  (range_B) 

or  4:  Some  combination  of  the  above 

It  is  very  difficult  to  decide  upon  which  backtracking  technique  to  adopt.  To  get  around  (his 
decision,  the  current  implementation  just  retracts  the  latest  cycle.  The  latest  cycle  is  cyclel3  and 
retracting  it  is  equivalent  to  adopting  strategy  1  (above).  By  popping  the  stark  for  variable  day 3, 
the  top  of  the  stack  now  is:  (cyc!el2  (2)).  On  propagating  this,  the  program  returns  successfully. 

Instead  of  ending  on  this  rather  encouraging  note,  we  shall  examine  likely  strategies  for 
backtracking.  Using  chronological  backtracking  can  often  be  very  inefficient.  There  should  be  some 
way  of  finding  out  the  best  strategy.  The  first  step  in  this  direction  is  the  identification  of 
dependencies.  In  other  words,  we  look  for  the  culprits,  the  variables  and  constraints  which  cause 
the  error  to  occur. 

An  error  occurs  when  a  constraint  tries  to  set  the  value  of  a  variable  to  the  empty  set  ()  The 
null  set  means  that  the  variable  got  over-constrained  and  that  the  constraints  have  forced  a 
contradiction  to  occur.  At  this  point,  the  culprits  are  the  corresponding  constraints  and  all  the 
variables  that  take  effect  through  that  constraint.  As  the  constraints  are  the  only  form  of  domain 
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dependent  knowledge,  backtracking  should  be  based  on  the  form  and  structure  of  the  constraints 
alone.  I  believe  that  the  constraints  can  be  pre-compiled  into  a  complex,  multi-referenced  network. 
This  symbolic  constraint  network  would  be  able  to  look-ahead  and  make  intelligent  choices.  An 
ability  to  look  ahead  is  valuable  because,  under  the  current  implcrr>c>'tationl  constraints  seem  to 
suddenly  pop  up  when  certain  choices  are  made.  The  constraints.  ;  s  some  sense,  lurk  about  the 
program  and  appear  suddenly,  often  to  the  dismay  of  the  scheduling  program. 

There  is  an  important  tradeoff  while  pre-compiling  the  constraints.  It  is  possible  that  the  time 
spent  in  developing  the  constraint  network  itself  might  waste  too  much  time,  one  might  be  better 
of  going  ahead  with  the  search. 
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Chapter  VI 


Future  Directions 
VI.1  Exploiting  the  Flexibility  of  CDL-II 
VI. 1.0  Personal  Constraint  sets 

In  real  world  scheduling  problems  there  are  several  people  involved  in  the  development  of  the 
schedule.  Each  person  has  his/her  own  requirements  off  the  schedule.  As  it  is  not  possible  to 
accommodate  all  the  people,  traditional  scheduling  programs  tend  to  have  a  few,  well  established 
constraints  hard  wired  into  the  system.  These  constraints,  however,  are  subject  to  change.  For 
example,  changes  in  the  staff  of  an  organization  can  bring  new  managers  who  have  unanticipated 
idiosyncrasies.  You  cannot  rewrite  old  software  to  accommodate  them! 

Given  the  framework  presented  in  this  thesis,  it  is  possible  to  input  the  constraints  of  several 
people  at  the  same  time.  Each  person  will  have  his/her  own  set  of  constraints.  The  computer 
consequently  tries  to  satisfy  all  the  constraints.  To  facilitate  usage,  one  would  have  to  develop  a 
higher  level  constraint  definition  language  than  the  one  (CDL-II)  presented  in  chapter  V.  Let  us  call 
this  natural  constraint  definition  language:  CDL-N. 

Armed  with  something  like  CDL-N  each  person  could  input  his/her  own  set  of  constraints. 
Further,  he/she  will  be  able  to  review  and  edit  the  constraint  sets  to  suit  his/her  personal  feelings. 
Each  set  of  constraints  will  consequently  reflect  the  personality  of  the  person  who  owns  it.  These 
data  sets  can  be  added  and  removed  when  required,  for  example:-  when  a  person  gets  transferred 
all  he/she  does  is,  take  his/her  constraint  sets  with  him/her  to  his/her  new  job  site.  Likewise,  if  a 
senior  manager  retires,  his/her  personality  can  be  retained  in  thi  form  of  CDL-N  statements. 

In  addition  to  personality  datasets  there  are  datasets  which  correspond  to  other  extraneous 
constrainls:- 

a)  Personality  dataset 

b)  Resources  dataset 
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c)  Shop  floor  constraints 

d)  Environmental  factors 

Environmental  constraints  can  cover  expected  conditions  like  snow  fall  or  financial  climate, 
depending  upon  the  application  one  is  dealing  with. 

The  system  uses  these  constraints  to  draw  up  a  plan  and  a  schedule.  It  may  not  be  possible 
to  satisfy  all  the  constraints.  Under  such  conditions,  the  system  will  initially  try  ot  satisfy  the 
constraints  which  rank  higher  (fuzzy  ranking).  Further,  a  person  higher  up  in  the  organizational 
structure  will  get  higher  weightages. 

Drawing  from  the  concept  that  an  organization  is  basically  an  information  processor  (at  some 
level),  one  will  be  able  to  model  the  whole  organization.  CDL-N  could  be  an  extension  to  the 
Business  Definition  Language  developed  by  IBM  corporation. 

VI.  1.2  What  If  Game* 

Once  the  constraint  sets  are  entered,  the  users  can  go  into  a  what  if  mode  and  can  change 
their  constraint  sets  to  see  how  sensitive  the  system’s  response  is  to  the  changes  he/she  makes. 

The  system,  in  the  process  of  scheduling  should  give  reports  on  costs,  resource  requirement, 
performance  standards  etc.  The  user  can  play  around  with  bis  data  set  and  see  how  he  can  best 
adjust  to  the  personalities  of  others. 

The  computer  may  even  be  able  to  ask  itself  what  if  questions. 

VI. 2  Handling  Multiple  Heuristics  In  Scheduling! 

•  towards  a  system  Architecture 
VI.2.0  Introduction 

This  section  explores  the  techniques  that  may  be  used  for  handling  multiple  heuristics. 
Several  researchers  in  Operations  Research  have  developed  heuristics  for  activity  scheduling.  Each 
of  the  heuristic  is  suitable  for  particular  types  of  problems.  None  of  the  heuristics  can  perform  well 


73 


in  all  scheduling  problems.  In  this  chapter  a  system  architecture  is  proposed  that  which  allows  one 
to  use  these  heuristics  as  and  when  required.  It  is  stipulated  that'.  If  one  could  find  out  the 
conditions  under  which  a  particular  heuristic  is  effective  or  ineffective,  then  it  may  be  possible  to 
recognize  patterns  and  invoke  the  heuristics  appropriately. 

In  section  II. 3  we  introduced  the  concept  of  the  scheduling  cycle.  In  figure  11.3.1  our  cycle 
looped  from  the  choice  of  ’who’  to  ’where'  to  'what'  to  ’when’  and  back.  There  are  two  very 
fundamental  questions  that  this  formalism  raises: 

1)  How  does  one  decide  upon  the  sequence  of  choices  in  the  scheduling  cycle. 

2)  Having  generated  some  choices  how  does  one  choose  which  to  pick. 

There  are  no  hard-and-fact  algorithms  or  techniques  by  which  these  problems  can  be 
addressed.  Only  heuristic  methods  can  be  used  to  perform  such  tasks. 

VI.2.1  Multiple  Heuristics 

Having  decided  to  work  with  heuristics,  how  does  one  decide  which  kinds  of  heuristics  are 
best  for  our  problem.  If  we  really  do  decide  upon  a  particular  heuristic,  is  it  possible  that  half  way 
through  the  scheduling  process  a  different  type  of  heuristic  might  be  more  relevant. 

Heuristics  come  in  all  shapes  and  sizes.  Aggressive  strategies  like  to  schedule  as  early  as 
possible.  "Wait  &  see"  strategies  exercise  least-commitment.  Backup  heuristics  help  in  undoing 
poor-choices. 

Here  are  some  examples:|  Moder  &  Phillips  1983] 

Name  of  Heuristic  consultant  Description 

Late  Finish  Give  priority  to  activities  in 

order  of  increasing  late  finish 
time. 

Minimum  Slack  Schedule  first  those  activities 

with  low  slack  time. 


Ik 


Random  Priority  given  to  jobs  selected 

randomly 

Bumping  If  there  is  a  clash,  then 

bump  the  activity  of  lower 
priority. 

Meta-OR  If  total  variables  in  the 

problem  <  5000  &  total 
constraints  <  5000  then  use 
Dynamic  Programming 

TABLE  I 

Given  a  set  of  heuristics  we  have  to  decide  which  one  is  most  useful.  Presumably  different 
strategies  are  relevant  in  different  situations.  In  addition  some  strategies  may  always  performs 
better  than  other.  There  are  two  ways  of  invoking  a  heuristics 

(a)  Pattern  directed 

(bj  Relative  grading 

Establishment  of  patterns  for  choosing  a  heuristic  is  very  tough.  The  meta-OR  heuristic  in 
Table  I  is  an  example.  We  do  not  have  any  good  ideas  in  this  area  yet. 

Heuristics  can  be  graded  relatively.  This  is  done  by  running  the  system  on  several  typical 
problems,  each  time  with  only  one  of  the  heuristics  in  place.  Performance  characteristics  of  each 
heuristics  is  gathered  and  is  used  to  rank  the  heuristics. 

VI.2.2  Search  Heuristics 

When  coming  down  the  search  tree  we  will  have  to  adopt  some  kind  of  pruning  mechanism. 
Having  used  some  of  the  heuristics  (like  those  in  Table  I)  we  reach  a  stage,  at  the  end  of  a 
scheduling  cycle,  where  there  are  several  viable  partial  schedules.  Due  to  time  &  computer  memory 
constraints  all  these  nodes  cannot  be  developed.  As  mentioned  in  Sections  II. 2  &  II. 3,  we  need  a 
function  by  which  the  nodes  can  be  evaluated  and  then  chosen  for  further  branching. 

From  equation  |3],  section  II. 2,  there  are  two  parts  of  a  evaluation  function:  (at  node  n) 
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T 


f(n)  =  g(n)  +  b(n) 

A  measure  of  goodness  of  a  node  is  based  on  utilities,  equati  .11  [l|  of  section  11.2  .  This  gives 
us  g(n)  only.  The  estimate  to  complete  is  found  by  doing  a  depth  first  search  from  the  node  in 
question.  Such  a  search  is  designed  to  be  a  lower  bound  on  the  total  utility  and  is  hence  conducted 
in  a  rash  manner;  constraints  are  not  fully  satisfied,  no  backtracking  is  performed,  due  dates  are 
violated  etc.  This  quick  ’look  ahead’  will  give  us  a  good  h(n)  to  work  v.ith.  We  now  choose  the  node 
with  highest  f(n). 

VI.3  System  Architecture 

Based  on  the  ideas  presented  till  now,  we  proceed  to  develop  an  architecture  : 

a)  The  constraints  are  defined  by  users  and  are  subject  to  change. 

b)  The  jobs  (battalions)  to  be  performed  are  ever-competing  to  be  chosen  next.  For  this 
reason  they  are  said  to  exist  in  a  market  of  jobs. 

c)  Each  heuristic  consultant  has  his  own  way  of  doing  things  they  may  either  support  one- 
another  or  give  raise  to  conflicting  situations.  For  this  reason  they  are  said  to  be  in  a  board  of 
consultants.  These  consultants  communicate  via  a  blackboard. 

With  this  we  are  able  to  hone  in  on  a  system  architecture.  Figure  VI.3.1  .  The  controller 
examines  the  advice  (bids)  deposited  on  the  blackboard.  A  consultant  is  chosen  and  applied  for  a 
few  scheduling  cycles.  The  constraints  are  used  as  outlined  in  sections  IV  &  V. 
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ABSTRACT 


IMST  is  a  tool  for  building  rule-based  systems.  It  has  been  built  to  merge  the  technologies  of 
Knowledge  Representation  in  Artificial  Intelligence  with  that  of  Relational  Database  Management 
systems.  While  maintaining  a  relational  (in  the  eyes  of  the  user)  type  database  it  allows  the  user  to 
operate  on  the  data  using  production  rules. 

IMST  also  allows  the  user  to  do  some  meta-level  control.  Rules  can  be  loaded,  and  unloaded. 
Facts  can  be  blaekboarded  for  easy  access  and  modularity. 

IMST  is  written  in  Franz-LISP  (with  parts  in  C)  and  is  built  for  the  user  who  is  not  familiar 
with  LISP.  It,  however,  does  allow  the  users  to  define  their  own  functions  and  even  their  own 
interface. 

Th  is  paper  explains  the  workings  of  IMST  through  the  use  of  numerous  examples. 
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1.0  Introduction 


IMST  is  an  environment  for  building  rule  based  expert  systems.  It  is  modeled  after  some  of 
the  popular  production  systems  like  OPS-5  (Charles  Forgy  '81  Carnegie-Mellon  U.)  and  YAPS  (Liz 
Allen  '83  Maryland). 

IMST  was  written  to  merge  the  technologies  of  rule  based  systems  with  that  of  data  base 
management.  It  allows  the  user  to  think  of  his/her  data  in  the  form  of  a  relational  database. 

The  system  is  written  in  Franz-Lisp  and  it  operates  in  a  UNIX  4.2  environment.  Even  though 
IMST  has  its  own  top-level  environment,  it  does  not  insulate  the  user  from  the  full  power  of  LISP. 

1.1  The  system  architecture 

IMST,  like  all  other  production  systems,  has  two  major  parts;  the  rule  base  and  a  data  base 
of  facts.  The  rules  operate  upon  the  facts  and  make  inferences.  These  inferences  are  added  back  to 
the  facts  list  and  are  then  available  for  use  by  the  other  rules. 

IMST  has  its  own  top-level  environment.  The  purpose  of  this  environment  is  to  let  users 
interact  with  the  system  without  knowing  any  LISP.  Once  an  application  is  developed,  the  IMST 
top-level  can  be  overridden  by  a  user  defined  interface. 

1.2  The  data  baae 

The  data  base  is  a  collection  of  sentences.  Each  sentence  is  an  assertion  about  the  domain  one 
is  dealing  with.  Data  can  be  entered  into  the  database  via  the  function  assert. 

The  assertions  are  stored  in  a  file  which  can  be  loaded  into  the  IMST  environment  by  using 
the  loadfile  command. 

Consider  a  world  about  which  we  have  the  following  information: 

"There  is  a  strong  boy  named  john  who  lives  on  33  Maple  Street.  There  is  a  beautiful  girl 
who  is  5.5  ft  tall.  They  both  are  good  dancers." 

This  information  can  be  broken  up  into  assertional  statements  and  can  be  stored  in  a  file  as 
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shown  in  figure  1.2.1  below. 


(assert  mary  is_a  girl) 

(assert  john  is_a  boy) 

(assert  john  is  strong) 

(assert  john  address  33_maple_street) 
(assert  john  is  a  good  dancer) 

(assert  mary  is  beautiful) 

(assert  mary  height  5.6) 

(assert  mary  is  a  good  dancer) 

Figure:  1.2.1 - - - 


The  database  of  facts  can  now  be  queried  and  can  be  used  by  a  rule  base. 

Whenever  an  assertion  is  made,  the  first  word  is  treated  as  an  object  and  all  subsequent 
assertions  having  the  same  first  word  are  grouped  together.  The  assertions  listed  above  will  be 
stored  in  the  database  like  this: 


john : 


mary : 


(john  is_a  boy)  (mary  is_a  girl) 

(john  address  33_maple_street)  (mary  is  beautiful) 

(john  is  a  good  dancer)  (mary  height  5.6) 

(john  is  strong)  (mary  is  a  good  dancer) 

Figure:  1.2.2 - 


The  reader  should  be  aware  that  there  is  no  restriction  on  the  contents  of  an  assertion.  The 
same  data  could  be  asserted  like  this: 


(assert  there  is  a  boy  named  john) 

(assert  he  is  strong  and  he  lives  on  33_maple_street) 
(assert  john  is  a  good  dancer) 

(assert  she  is  mary) 

(assert  she  dances  well) 

(assert  mary  is  five  feet  6  inches) 


(assert  she  is  beautiful) 


Figure:  1.2.3 - 

The  semantic  content  is  the  same  but  there  is  no  modularity  and  consistency.  The  facts 
(mary  dances  well)  and  (john  is  a  good  dancer)  may  be  the  same  for  the  user  but  not  to  (he 
computer.  The  use  of  statements  like  (she  is  beautiful)  can  be  very  misleading.  It  is  advisable  to  use 
the  (<object>  <attribute>  <value>)  format  .  In  essence,  consistency  is  highly  desirable. 

Before  closing  this  section  it  is  useful  to  know  that  a  database  fact  can  be  removed  by  the 
unasaert  function.  The  file: 


(unassert  john  is  strong) 

(unassert  john  isa  boy) 

(unassert  john  is  a  good  dancer) 

(unassert  john  address  33jnaple_street) 

Figure  1.2.4 - 

will,  when  loaded,  delete  all  the  information  on  john. 
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2.0  An  example 


2.1  Introduction 

This  chapter  is  intended  to  instruct  the  user  about  the  use  of  IMST.  It  contains  a  simple 
example  and  attempts  to  explain  the  important  features  of  IMST  through  the  example. 

In  section  1.2  the  notion  of  an  assertional  database  was  introduced.  We  now  show  how  the 
data  may  be  used  by  production  rules. 

A  production  rule  is  basically  an  IF-THEN  rule.  A  rule  states  that  IF  certain  facts  are  true 
THEN  there  are  a  few  other  facts  that  are  deemed  true. 

The  example  below  is  a  fully  annotated  trace  of  the  IMST  environment.  The  text  in  boldface 
is  which  is  typed  in  by  the  user.  The  text  in  italics  is  the  explanation  and  the  normal  typeface  is 
that  which  is  printed  by  the  computer. 

2.2  Example 

S.S.l  First  the  data: 

To  start  IMST  one  first  logs  into  the  UNIX  system  where  the  program  has  been  installed. 
After  logging  in  just  type  ’imst'  to  the  unix  shell 

unixX  Imst 

This  may  be  followed  by  a  few  system  messages  and  in  about  5-8  seconds  you  will  find  yourself 
with  the  IMST  prompt:  'imst>  ’.  The  first  thing  to  do  is  to  initialize  the  system  mth  the  'init' 
command 

imst>  Inlt 

Now  let  us  input  some  data.  The  data  is  normally  added  to  the  system  via  a  file.  To  create 
such  a  file  we  can  go  into  the  editor  by  using  the  ’emacs'  command.  Let  us  call  the  file  ’people' 

imst>  emacs  people 

This  will  put  you  into  a  full  screen  editor.  If  you  are  not  familiar  with  emacs  you  could  usi  the 
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command:  'vi'  ( for  the  unix  visual  editor).  Here  is  how  the  data  is  entered  in  the  file. 


(assert  John  ls_a  boy) 

(assert  John  height  6.0) 

(assert  John  gpa  3.8) 

(assert  John  likes  sailing) 

(assert  Jack  is_a  boy) 

(assert  Jack  height  6.5) 

(assert  Jack  gpa  5.0) 

(assert  mary  Is  m  girl) 

(assert  mary  is  beautiful) 

(assert  mary  gpa  4.2) 

(assert  mary  height  5.5) 

(assert  mary  likes  sailing) 

(assert  boy  is  a  person) 

(assert  girl  is  a  person) 

(assert  person  ls_a  mortal) 

(assert  person  has  a  soul) 

Figure:  2.2.1  . 

Having  typed  the  data  in,  exit  emacs  normally.  This  will  put  you  back  in  IMST.  You  ore  now 
ready  to  load  the  file. 


im&t>  load  file  people 


The  above  command  will  produce  the  following 


data  base  in  IMST 


John:  (john  is_a  boy) 
(john  height  6.0) 
(john  gpa  3.8) 
(john  likes  sailing) 

mary:  (mary  is_a  girl) 
(mary  is  beautiful) 
(mary  gpa  5.0) 
(mary  height  5.5) 
(mary  likes  sailing) 


jack:  (jack  is_a  boy) 
(jack  height  5.5) 

(jack  gpa  5.0) 

girl:  (girl  is _ a  person) 

boy:  (boy  is_a  person) 

person:  (person  is_a  mortal) 
(person  has  a  soul) 


Figure  2.2.2 
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There  is  a  way  of  viewing  this  data.  This  is  shown  below: 

imst>  describe  John 

Description  of  object:  john 

is_a  boy 
height  6.0 
gpa  3.8 

imst> 

2.2.2  Now  for  some  rules 

A  rule  consists  of  a  set  of  facts  (patterns)  in  the  IF  part,  followed  by  a  set  of  actions  in  the 
THEN  part.  The  IF  &  THEN  parts  are  separated  by  a  implication  sign 

Here  is  the  syntax: 

(rule  -name-  -pattern_l-  -pattern_2- 
....  -pattern  _n- 

— >  -action_l-  -action_2-  ....  -action_m-) 

Assume  that  we  want  to  conclude  that  john  knows  how  to  swim  because  we  know  that  he  likes 
sailing.  Here  is  what  the  rule  may  look  tike  : 

(rule  john_swim  (john  likes  sailing) 

— >  (assert  john  knows  swimming)  ) 

There  is  only  one  pattern  in  this  rule  and  when  the  rule  is  run,  it  will  fire  because  the  pattern 
(john  likes  sailing)  is  found  to  exist  in  the  database.  The  action  ' assert ’  will  odd  (john  knows 
swimming)  to  the  database. 

There  is  a  problem  here,  we  also  want  to  conclude  that  mary  can  swim  because  she  too  goes 
sailing.  The  rule  should  be  able  to  handle  all  those  who  like  sailing.  In  other  words  the  rule  should  be 
able  to  handle  variables.  Here  is  what  it  might  say  ’IF  there  is  an  which  likes  sailing,  then  assert 


that  that  'x' knows  swimming 


This  is  done  by  introducing  a  variable  into  the  pattern.  The  pattern  (>x  tikes  sailing)  will 
match  any  fact  which  has  any  object  with  the  words  'likes’  &  'sailing'  in  the  attribute  and  value 
positions.  In  other  words,  (>x  likes  sailing)  will  match  the  fact  (john  likes  sailing)  and  (mary  likes 
sailing)  and  unll  bind  x  to  john  &  mary  respectively. 

Assuming  x  is  bound  to  ’john’,  the  assertion  (assert  <x  knows  swimming)  will  actually  assert 
(john  knows  swimming).  The  use  of  the  the  symbol  >  before  a  variable  name  means  ” bind  this 
variable "  &  the  symbol  <  means  "lookup  the  value  \ 

A  mnemonic  way  of  looking  at  this  is: 

>x  can  be  looked  upon  as  —  >x  ,  that  is,  a  value  going 
into  x 

and  <x  can  be  looked  upon  as  <— x  ,  that  is,  the  value  coming 
out  of  the  variable  x 

Let  us  now  write  the  rule  in  a  file  called  'rule' 

(rule  swimming  _  rule  (>x  like*  Milling) 

— >  (assert  <x  knows  swimming)) 


imst>  loadfile  rule 

imst>  run 

Trying  rule:  swimming_rule 

asserting  >  (john  knows  swimming) 
asserting  >  (mary  knows  swimming) 


done 


imst>  describe  john 


Description  of  object  john 

is_a  boy 
height  6.0 
gpa  3.8 
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likes  sailing 
knows  swimming 


Notice  that  the  data  for  object  john  has  been  updated.  We  now  go  on  to  write  some  more 

rules: 

Here  is  a  rule  that  says  that  any  boy  with  a  gpa  of  5.0  is  a  nerd  (we  have  a  5.0  system  for 

Grade  point  average  here  at  MIT). 

(rule  nerd  (>x  gpa  5.0 
(<x  is_a  boy) 

— >  (assert  <x  is_a  nerd)) 

Here  is  how  the  rule  works: 

The  first  pattern  will  match  (jack  gpa  5.0)  and  x  will  be  bound  to  ’jack’.  The  second  pattern 
has  a  lookup  for  x  and  will  become  (jack  is_a  boy).  As  the  second  pattern  is  found  in  the  data  base, 
the  rule  will  fire  and  (jack  is_a  nerd)  will  be  asserted.  Notice  that  the  rule  will  not  fire  for  mary. 
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2.2.3  More  examples 

a)  "If  any  boy's  height  is  greater  than  6  feet,  then  he  is  tall” 

We  now  introduce  yet  another  part  of  the  IMST  rule:  the  test.  A  test  is  a  function  that  either 
returns  true  or  false. 


(rule  tallboys  (>al  is_a  boy) 

(<al  height  >ht) 
test  (ge  <ht  6.0) 


— >  (assert  <al  is  tall)  ) 


The  rule  says:  "IF  there  is  a  boy  ’al’  of  height  ’ht*  and  if  ’ht’  is  greater-than-or-equal-to  (ge) 
6.0  then  assert  that  ’al’  is  tall.” 

b)  "If  any  boy  is  less  than  6.0  feet  tall  but  greater  than  5.5  feet  in  height,  then  that  person  is 
of  average  height" 


(rule 

a ve  r age_h  e i gh  t_boys 
(>x  is_a  boy) 

(<x  height  >ht) 

test 

(ge  <ht  6.6) 

(It  <ht  6.0) 

— >  (assert  <x  is  ofaverageheight) ) 


c)  "All  beautiful  girls  like  nerds” 


(rule  only_at_mit 

(>x  is_a  girl) 

(<x  is  beautiful) 
(>y  is_a  nerd) 

-->  (assert  <x  likes  <y)) 


Notice  how  this  rule  uses  the  inference  made  by  rule  "nerd"  of  section  2.2.2 


d)  "To  find  who  is  taller  than  whom 


(rule  taller  (>x  height  >xht) 

(>y  height  >yht) 
test  (gt  <xht  <yht) 

— >  (assert  <x  is  taller  than  <y)) 

e)  Now  an  interesting  rule  on  inheritance: 

Inheritance  is  an  important  part  of  building  object  based  semantic  networks.  If  an  object  ’>■' 
is_a  object  ’x'  (eg.  dog  is_a  animal),  then  the  object  ’y’  should  inherit  the  propertis  of  ’y'. 
Stated  in  rule  form  we  have: 

"If  there  is  any  object  x  with  property  px  and  value  vx  and  if  some  y  is_a  x  then  y  should 
also  have  the  property  px  and  value  vx" 

(rule  inheritance  (>y  is_a  >x) 

(<x  >px  >vx) 

— >  (assert  <y  <px  <vx)) 

If  we  run  this  rule  on  the  data  in  2.2.2  we  will  get  the  following  assertions 


(jack  is_a  person)  (jack  is_a  mortal)  (jack  has  a  soul) 
(mary  is_a  person)  (mary  is_a  mortal)  (mary  has  a  soul) 
(john  is_a  person)  (john  ie_a  mortal)  (john  has  a  soul) 


You  have  just  been  exposed  to  the  most  important  part  of  IMST  and  are  ready  to  write  rule 
based  systems! 

f)  A  arithmetic  rule:  To  convert  the  height  to  meters. 

(rule  f eet_to_meters 
(>x  height  >y) 

-->  (unassert  <x  height  <y) 

(assert  <x  heightmetric 

(/  (*  (*  <y  12.0)  2.64)  100.0)  )) 


92 


3.0  The  rule  Syntax 


3.1  The  rule 

The  rule  in  IMST  are  of  Ihe  following  form 

(rule  -rulename-  -pattern_l- 

-pattern_2- 
.  -pattern_n- 

test  -test_l-  -te8t_2- 

.  -test_p- 

— >  -action_l-  -action_2-  .  -actionjn-  ) 

The  use  of  tests  is  optional.  If  there  are  no  tests,  simply  drop  the  word  ’test’  from  the  body  of 
the  rule. 

The  rule  fires  when  all  the  patterns  match  &  all  the  tests  are  true.  The  tests  are  evaluated 
using  the  lisp  eval,  the  same  goes  for  the  actions. 

3.2  Teat  Predlcatea 

There  are  several  predicates  that  are  provided  by  IMST: 

(ge  -argl-  -arg2-)  Returns  true  if  argl  is  greater  than  or  equal  to  arg2. 

(le  -argl-  -arg'2-)  Less  than  or  equal  to 
(**  -argl-  -arg2->  Greater  than. 

(It  -argl-  -arg2-  |  Less  than. 

(=  -argl-  -argj-)  Equal  to 
(ne  -argl-  -arg2-)  Not  Equal  to 

(not*  -pattern I-)  The  patternl  does  not  exist  in  the  database. (  The  pattern  should  not  have 
any  variables  in  it.) 
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3.3  Actions 


The  most  common  action  is  assert.  One  can  use  any  user-defined  LISP  function.  By  using 
Franz  Lisp’s  Fasl  function  it  is  possible  to  include  actions  that  are  written  in  C  or  Fortran. 

The  other  pre-defined  actions  provided  by  IMST  are  presented  in  the  following  chapters. 
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UNCLASSIFIED 


ML 


4.0  Database  Capabilities 


In  building  real-life  systems,  it  is  not  possible  to  have  a  long  data  file  full  of  assertions.  IMST 
has  a  ability  to  handle  tabular  data. 

4.1  Tabular  Data 

4.1.1 

It  is  popular  to  think  of  data  in  a  tabular  form.  IMST  allows  you  to  input  data  in  this  form. 
Consider  the  table  below 


student  ID# 

Gpa 

Height 

john  43433 

3.8 

6.0 

jack  39393 

5.0 

5.5 

mary  39204 

5.0 

5.5 

The  data  is  converted  into  object-attribute-value  triples  automatically  .  Here  is  what  will  be 
asserted  for  john: 

(john  ID#  43433) 

(john  gpa  3.8) 

(john  height  6.0) 

(john  is_a  student) 

The  above  'is _ a’  relationships  are  implied  by  the  virtue  of  the  fact  that  the  names  john,  jack 

&  mary  are  listed  below  the  field  'student'. 

4.1.2  The  create,  edit  &  loaddata  commands. 

create 

The  create  cdmmand  takes  no  arguments  and  is  used  to  create  a  table.  Here  is  a  self 
explanatory  example: 
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imst>  create 


Name  of  the  file  =>  people 

type  ‘quit*  to  finish  up 

Field  1  => student 
Field  2  =>  ID# 

Field  3  =>  gpa 
Field  4  =>  height 
Field  6  =>  quit 

imst> 


A  file  should  be  created  only  once.  Having  created  the  file,  it  is  now  ready  for  editing. 

edit 

edit  takes  no  arguments  and  it  is  used  to  edit  a  tabular  data  file.  It  allows  one  to  input  data 
record  by  record.  It  can  be  used  to  edit  old  files  too. 

The  editor  is  currently  very  simple,  it  only  allows  you  to  go  forward  from  field  to  field  &  from 
record  to  record.  After  typing  in  data  one  can  exit  the  editor  by  hitting  return  on  a  blank  line  only. 
If  you  make  a  mistake,  you  will  have  to  exit  the  editor  and  re-enter  the  editing  routine,  you  cannot 
go  back. 

Note:  The  editor  forces  you  to  use  a  directory  to  store  your  files.  You  can  choose  your  current 
directory  by  providing  the  appropriate  pathname  in  full. 

For  example:  If  we  wish  to  store  the  above  file  'people'  in  a  sub-directory  called  'knowledge- 
base',  then  the  trace  may  look  like  this: 


imst>  edit 

Give  me  a  directory  name  =>  knowledge-base 

Name  of  the  data  file  within  the  above  directory  =>  people 
Which  record  would  you  like  to  Btart  at? 

(if  this  is  a  new  file,  start  at  #1)  =>  1 


loaddata 


This  function  takes  no  arguments  and  it  is  used  to  load  in  a  file  which  was  a  product  of  the 
create  and  edit  commands.  It  automatically  converts  the  records  into  a  frame  representation  and 
makes  the  appropriate  assertions. 

4.3  Database  actions 

Here  are  some  of  the  database  actions  that  IMST  can  perform  within  the  body  of  a  rule: 
(assert  ...data...)  To  assert  data  into  the  database. 

(unassert  ....data...)  To  remove  a  data  element  from  the  database. 

(glue  string_l  string_2)  It  is  used  to  create  new  objects.  For  example:  If  x  is  bound  to 
’john’  and  we  wish  to  create  a  new  object  called  ’johns  girlfriends’  then  one  could  use: 

(assert  (glue  <x  s_ girlfriends)  ....data....) 

(cardinality  objectl)  Counts  the  number  of  facts  within  a  given  objectl. 

(summation  fieldl  objectl)  Returns  the  summation  of  a  particular  field  from  an  object.  It 
requires  that  the  selected  object  has  the  specified  in  the  ’value’  position  (rightmost)  in  each  fact. 

(average  fieldl  objectl)  Same  as  summation,  only  it  returns  the  arithmetic  mean  . 
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5.0  Miscellaneous  Actions 


5.1  Meta  Level  Control 

The  rule  base  in  IMST  exists  in  two  areas,  the  active  and  the  inactive  set. 

(awapln  rule!)  This  will  swapin  the  rulel  into  the  active  set  from  the  inactive  set. 

(■wapout  rulel)  Will  send  an  active  rule  to  the  inactive  set. 

(rmrule  rulel)  Will  remove  the  rulel  from  the  active  set,  forever. 

(loadflle  file _ 1 )  This  will  load  the  file  IMST  into  the  top-level  and  is  useful  for  pattern 

invoked  loading  or  rulebases. 

(lnltrulea)  Will  clean  up  all  the  rules  in  the  current  active  ruleset. 

5.2  I/O  Commanda 

(skip  n)  Skips  V  lines. 

(tab  n)  Will  tab  cursor  forward  by  n  columns. 

(say  ...message....  )  The  say  action  is  like  assert  but  does  not  assert  the  message  but  just 
echo’s  it  to  the  screen. 

(aak  ...question....)  It  will  accept  a  value  for  a  variable  in  the  text  of  the  question.  For 
example: 

(ask  What  is  your  >name) 

The  system  will  stop  and  wait  for  input  from  the  user.  The  input  will  be  bound  to  the 
variable  ’name’  . 


98 


6.0  Top-Level  Command  Summary 

A  summary  of  all  the  commands  that  can  be  issued  from  the  IMST  top-level. 

create  Creates  table 

describe  object  Returns  a  description 

dumpllsp  filename  Will  dump  the  whole  system,  the  data,  the  rules  and  IMST  into  the 
specified  file.  You  need  about  2.0  megabytes. 

edit  Edit  a  created  table 

etnaes  file  Edit  a  unix  file  using  emacs. 

help  Gives  some  help 

lnlt  Initializes  the  whole  system. 

Inltrules  Throws  away  the  current  ruleset  but  not  the  data. 

lisp  Lets  you  talk  to  Franz  lisp  directly. 

loaddata  Used  for  tabular  data  loading. 

loadflle  filename  Will  load  the  specified  file. 

quit  Quit 

run  Starts  the  inference  Engine 
top  Return  to  top-level  of  IMST. 
vl  file  The  unix  vi  editor 
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7.0  IMST  function  list 


The  test  and  actions  in  IMST  can  be  any  lisp  function.  IMST  comes  with  a  library  of  useful 
functions: 

Arithmetic  functions: 

The  operators:  +  /  *  - 

The  predicates:  gt  It  ge  le  —  ne  not* 

Database  operations: 

assert 

unassert 

glue 

cardinality 
summation  average 

I/O 

say 

ask 

skip 

tab 

Meta-level  Control 

swapin 
swapout 
rmrule 
load  file 
loaddata 


initmles 
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APPENDIXB 


Trace  of  a  ran 

This  appeadix  is  the  trace  of  a  ran.  It  has  three  part: 

Parti  The  iaput  data  to  the  program. 

Partll  The  coastraiats  (ia  CDL-II) 

PartlH  Aa  aaaotated  trace  of  the  raa. 

The  example  ased  here  is  aa  exteatioa  of  the  ease  preseated  in  Chapter  I. 
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Appendix  B 
Part  I 

Tke  iapat  data 
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;;TH  E  INPUT  DATA 


;;  This  file  contains  the  data  used  for  the  trace  of  CDLcil 
;;  It  contains  the  definition  of  all  the  schedule  elements 


;■  The  TIME  PERIODS  &  FIRING  RANGES 

;;  Setting  the  full  time  period  to  be  one  month 

(set  'one_  month  ’(1  2  3  4  5  *  7  8  9  10  11  12  13  14  15  18  17  18 
10  20  21  22  23  24  25  28  27  28  20  30  )) 

;;  Setting  the  holidays 

(set  'holidays  (1  8  14  22  28)) 

;;  Setting  sub  time  periods:  early  and  late. 

(set  'early  '(1  2  3  4  5  6)) 

(set  late  '(26  27  28  20  30)) 

;;  Setting  the  firing  ranges 

(set 'all _ ranges '(range _ A  range  B  range  C  range_D  range _E  range  _F)) 


;;  THE  BATTHONS 

;;  Defining  the  battalions  and  their  schedule  elements 


;•  BATTALION  :  bat_A 

;;  The  first  schedule  element,  "bat_A  will  carry  out 
;;  act_A  on  any  range  any  time  of  the  total  period 

(assert  bat_A  actAl  rangeAl  dayAl) 

(set  value  'actAl  '(*ct_A)) 

(set  __  value  'dayAl  one  _  month) 

(set __ value  'rangeAl  ’(range __ A  range_B  range_C)) 

;;  The  second  schedule  element: 

(assert  bat  A  actA2  range A2  dayA2) 

(set  value  ’dayA2  one  montb) 

(set  value  'rangeA2  ’(range_  A  range  B  range_C)) 
(set  value  'artA2  ’(act_A)) 

;;  The  third  schedule  element 

(assert  bat_A  actAS  range  AS  day  AS) 

(set_value  'day A3  one  month) 

(set _  value  ’rangeAl  '(range  A  range _B  range_C)) 
(set _  value  'actA3  '(act_A)) 


103 


;;  The  fourth  schedule  element 


(assert  bat_A  scEAt  range A  4  dayA4) 

(set  value  'actA4  ’(act_B)) 

(set  value  ’rangeA4  all  ranges) 

(set  value  ‘dayA4  early) 


;;  BATTALION  ’B’ 

;;  First  Schedule  element: 

(assert  bat  B  actBl  rangeBl  dayBI) 

(set_value  'dayBI  one  month) 

(set  value 'rangeBl  all  ranges) 
(set_  value  'actBl  '(act_  B)) 

;;  the  second  schedule  element: 

(assert  bat _B  actB2  rangeB2  dayB2) 

(set _ value  'artB2  '(act_A)) 

(set  _  value  'rangeB2  all  ranges) 

(set  value  'dayB2  late) 

;;  the  third  schedule  element: 

(assert  bat  B  actB3  rangeBS  dayB3) 

(set_value  'actB3  '(act_C)) 

(»«*■ _ value  'rangeB3  all  ranges) 

(set  value  'dayB3  late) 


;;  BATTALION  "C" 

;  the  first  element 

(assert  bat  C  artCl  ranged  dayCI) 

(set  value  'actCI  '(act_A)) 

(set  value  'rangeCl  all  ranges) 

(set  value  'dayCI  one  month) 

;;  the  second  element 

(assert  bat_C  actC2  rangeC2  dayC2) 

(set  value  ’aetC2  ’(act  B)) 

(set  value  'rangeC2  all  ranges) 
(>*t_  value  'dayC2  early) 

;;  the  third  elememnt 

(assert  bat_C  actC3  rangeC3  dayC3) 

(set  value  ’actC3  ’(act  B)) 

(set  value  ’rangeC3  all  ranges) 
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(set  _  value  ’dayC3  one  _  month) 


;;  BATTALION  ”D" 

;  the  first  element 

(assert  bat  D  aetDl  rangeDl  dayDI) 

(set _ value  'aetDl  ’(act_A)) 

(set  _  value  ’rangeDl  all  _  ranges) 

(set_  value  'dayDI  early) 


;;  the  second  element 

(assert  bat_D  actD2  rangeD2  dayD2) 

(set_value  'actD2  '(act_A)) 

(set  _  value  'rangeD2  all  _  ranges) 

(set  value  'dayD2  late) 
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Appendix  B 
Part  II 

The  Constraints  (in  CDL-II) 
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;;  THE  CONSTRAINTS  (IN  CDL-II) 

;;  The  constraint  set  presented  here  is  used  in  the  attached  trace  of 
;;  the  program. 


r 


;;  CONSTRAINT  Cl 

;;  A  battalion  can  do  only  one  activity  per  day 

(constraint  Cl  (>bat  >act  >  range  >day) 
test  (selected?  <day) 

->  (constraint  cl_aux(<bat  >al  >rl  >dl) 
test  (not  (equal  (quote  < day)  dl)) 


—  >  (set_value  dl 

(subtract  (get  value  dl) 

(get_  value  (quote  <day)))) 


)) 


CONSTRAINT  C2 

»♦ 

;  Constraint  2::  Two  battalions  cannot  be  on  the  same  range 
;  on  the  same  day. 

(constraint  C2  (>bat  >act  >range  >day) 
test  (selected?  <  range  <day) 

->  (constraint  C2_one(>b2  >a2  >r2  >d2) 

test  (not  (equal  a2  (quote  <act)))  ;  make  sure  its  not  the  same  one! 
(equal  (get_value  r2)  (quote  1  (get_value  range))) 

-  >  (set  value  d2 

(subtract  (get  _  value  d2)  (quote  I  (get  _ value  day))))) 

(constraint  C2_two  (>b3  >a3  > r3  >dS) 
test  (not  (equal  a 3  (quote  <act))) 

(equal  (gct_value  d3)  (quote  I  (get_value  day))) 

->  (set_value  r3 

(subtract  (get_  value  rS)  (quote  I  (get_  value  range)))))  ) 


;;  CONSTRAINT  CS 
;;  constraint  CS 

;  if  any  battalion  is  scheduled  for  activity  act_B  then  that 
;  battalion  should  not  be  scheduled  for  anything 
;  the  very  next  day. 
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(constraint  03 

(>bat  >act  >  range  >day) 
test  (selected?  <day  <act) 

(equal  (get  _  value  act)  '(act_B)) 

~>  (constraint  C3_aux  (< bat  >al  >rl  >dl) 
test  (not  (equal  (quote  <day  )  dl)) 

—  >  (set_value  dl 

(subtract  (get_  value  dl) 

(list  (+  1  (car  (get  value  (quote  <  day)))))))  )) 


;;  CONSTRAINT  C4 


Constraint  C4 

assignment  of  ranges  to  activities 


;  actvity 

acceptible  ranges 

;  act_A 

range  A  range  _B 

;  act_B 

range  _C 

;  act_C 

range  _B 

(constraint  C4_one  (>bat  >act  >range  >day) 
test  (equal  (get_value  act)  '(act  A)) 

-->  (set_value  range  ’(range  A  range  B))) 

(constraint  C4_two(>bat  >act  >range  >day) 
test  (equal  (get_ value  act)  ’(act_B)) 

->  (set  value  range  '(range  C))) 

(constraint  C4_ three  (> bat  >act  >range  >day) 
test  (equal  (get  value  act)  ’(act_C)) 

->  (set_ value  range  ’(range_  B))) 


CONSTRAINT  CO 


Cyclic  constraint  on  activity  act_A. 
the  window  is  set  at  x+S  and  x-t-10 


(constraint  C0_ one  (bat_  A  actAl  rangeAl  dayAl) 

;  being  specific  to  battalion  _  one 
;  could  be  done  automatically  . 

-->  (set  _  value  ’dayAS  (restrict  (get  _  value  ’dayAS) 

’(and  (ge  lil  (+  (get  _  min  _  value  ’dayA2)  5)) 
(le  $$$  (+  (get  _  max  _  value  ’dayA2)  10))))) 

(set  _  value  'dayA2  (restrict  (get  value  'dayA2) 

’(and  (ge  $$$  (+  (get  _ min __  value  ’dayAl)  6)) 
(le  $$$  (+  (get _ max _ value  ’dayAl)  10)) 
(le  III  (-  (get_max_value  ’dayAS)  5)) 

(ge  $$$  (-  (get  _  min  _  value  ’dayAS)  10))))) 
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(set  value  'dayAl  (restrict  (get_value  ’dayAI) 

’(and  (le  )$$  (-  (get  _  max  _ value  ’dayA2)  5)) 
(ge  $$$  (-  (get_  min  _  value  ’dayA2)  10))))) 


) 


;;  CONSTR1ANT  C7 
;;Constriant  C7 

;;  The  safety  spans  constraint:  When  act  A  is  carried  out  on  range  _  A 
;;  then  the  safety  spans  requires  that  it  is  unsafe  to  schedule  anything  on 
;;  range_C 


(constraint  C7_safety_spans  (>bat  >act  > range  >day) 

test  (selected?  <day  <act  <  range) 

(equal  (get  _  value  act)  '(  act_A)) 

(equal  (get  value  range)  ’(  range  _  A)) 

;;  has  two  parts:  If  the  range  is  range_C  then  do  not  use  the  day 
;;  If  the  day  is  the  same  then  do  not  use  range_C 

~>  (constraint  C7_aux  ( > bb  >aa  >rr  >dd) 
test  (not  (equal  aa  (quote  <act))) 

(equal  (get  value  rr)  ’(range_C)) 

->  (set  _  value  dd 

(subtract  (get  _  value  dd) 

(get_  value  (quote  <day))))) 

(constraint  C7_aux_aux  (>bbb  >aaa  >rrr  >ddd) 
test  (not  (equal  aaa  (quote  < act))) 

(equal  (get  _  value  ddd)  (quote  <day)) 

—  >  (set_  value  rrr 

(subtract  (get  value  rrr) 

’(rangeC))))) 


•;  CONSTRAINT  C8 


;;;  Constraint  CO  :  "there  shall  be  no  training  on  holidays* 


(constraint  CO  (>bat  >act  >  range  >day) 

-> 

(set  _  value  day 

(restrict  (gel_value  day) 

'(not  (member  III  holidays))))) 
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Appendix  B 
Part  HI 

The  Trace  of  the  Program 

This  trace  uses  the  data  and  the  constraints  shown  in  parts  I  and  II  of  this  appendix.  The 
program  is  started  by  entering  lisp,  loading  the  program,  the  data,  and  then  issuing  the  command  : 
(search) 

The  program  follows  the  algorithm  oulined  in  section  V.3  of  this  thesis.  The  main  steps  are: 

(1)  Try  to  propagate  the  constraints. 

Whenever  a  constraint  causes  an  effect 
the  new  value  is  echoed  along  with  the 
current  cycle  number. 

At  the  end  of  each  propagate  cycle  the 
program  echoes  "PROPAGATION  COMPLETE" 

(2)  After  the  above  step,  it  branches  and  sets  up 
new  contexts.  The  word  "BRANCHING"  is  echoed 
on  the  screen . 


If  during  the  propagation  stage  the  program  encounters  a  contradition,  it  backs  up  and 
"PURGES”  the  latest  context. 
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Script  started  on  Wed  May  8  10:43:81  1086 
hera%  rsh  hades  lisp 
Frans  Lisp,  Opus  38.01 


->  (load  ’RliN.l) 
load  RUN.I| 

fast  compiled/rulengine.o] 
fas)  compiled/cdl.oj 
fasl  compiled/utils.o) 
fasl  compiled/search.o] 

you  will  have  to  load  data  and  then  issue  command  (search)t 

•  >  (load  ’data.l) 

[load  data.l] 

asserting  >  (bat_A  actAl  rangeAl  dayAl) 

Setting  value  of  actAl  to  (act_A)  with  context  ■■  cycle 

Setting  value  of  dayAl  to  (1  2  3  4  6  8  7  8  0  10  11  12  13  14  IS  18  17  18  10  20  21  22  23  24  25  28  27  28  20  30)  with  conte 
Setting  value  of  rangeAl  to  (range__A  range_B  range_C)  with  context  —  cycle 
asserting  >  (bat  A  actA2  rangeA2  dayA2) 

Setting  value  of  dayA2  to  (1  2  3  4  5  8  7  8  0  10  11  12  13  14  15  18  17  18  10  20  21  22  23  24  25  28  27  28  20  30)  with  conte 
Setting  value  of  rangeA2  to  (range_A  range  B  range_C)  with  context  “  cycle 
Setting  value  of  actA2  to  (act_A)  with  context  —  cycle 
asserting  >  (bat_A  actAS  rangeAS  day  A3) 

Setting  value  of  dayAS  to  (1  2  3  4  5  8  7  8  0  10  11  12  13  14  1$  16  17  18  10  20  21  22  23  24  25  28  27  28  20  30)  with  conte 

Setting  value  of  rangeA3  to  (range_A  range_B  range_C)  with  context  =  cycle 

Setting  value  of  actAS  to  (act_A)  with  context  cycle 

asserting  >  (bat_  A  actA4  rangeA4  dayA4) 

Setting  value  of  actA4  to  (act  B)  with  context  — >  cycle 

Setting  value  of  rangeA4  to  (range_A  range_B  range_C  range_D  range_E  range_F)  with  context  ■«  cycle 
Setting  value  of  dayA4  to  (1  2  3  4  6  6)  with  context  «*  cycle 
asserting  >  (bat_B  actBl  rangeBl  dayBl) 

Setting  value  of  dayBl  to  (1  2  3  4  5  8  7  8  0  10  11  12  13  14  16  16  17  18  10  20  21  22  23  24  25  26  27  28  20  30)  with  conte 

Setting  value  of  rangeBl  to  (range_A  range_B  range_C  range_D  range_E  range_F)  with  context  “  cycle 

Setting  value  of  actBl  to  (act_B)  with  context  ■»  cycle 

asserting  >  (bat_B  actB2  rangeB2  dayB2) 

Setting  value  of  actB2  to  (act_A)  with  context  ■“  cycle 

Setting  value  of  rangeB2  to  ( range _ A  range  B  range_C  range_D  rangeE  rangeF)  with  context  >•  cycle 

Setting  value  of  dayB2  to  (26  27  28  20  30)  with  context  cycle 

asserting  >  (bat_B  actBS  rangeBJ  dayB3) 

Setting  value  of  actB3  to  (act_C)  with  context  —  cycle 

Setting  value  of  rangeB3  to  (range _  A  rangeB  range_C  range_D  range_E  range  F)  with  context  cycle 
Setting  value  of  dayB3  to  (26  27  28  20  30)  with  context  ■■  cycle 
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asserting  >  (bat_C  actCl  rangeCl  dayCl) 

Setting  value  of  aetCl  to  (act  A)  with  context  =  cycle 

Setting  value  of  rangeCl  to  (range  A  range  B  rangeC  range_D  rangeE  range  F)  with  context  —  cycle 

Setting  value  of  ilayCl  to  (I  2  3  4  5  8  7  8  fl  10  11  12  13  14  15  18  17  18  10  20  21  22  23  24  25  28  27  28  20  30)  with  conte 

asserting  >  (bat  C  actC2  rangeC2  dayC2) 

Setting  value  of  aclC2  to  (act  B)  with  context  =  cycle 

Setting  value  of  rangeC2  to  (range  A  range _  B  range  _C  range  _D  range  _E  range  F)  with  context  =  cycle 

Setting  value  of  dayC2  to  (1  2  3  4  S  8)  with  context  =  cycle 

asserting  >  (bat_C  actC3  rangeC3  dayC3) 

Setting  value  of  actC3  to  (act  _B)  with  context  =  cycle 

Setting  value  of  rangeCS  to  (rangeA  range  B  range_C  range  D  rangeE  range_F)  with  context  =  cycle 

Setting  value  of  dayCS  to  (1  2  3  4  5  8  7  8  0  10  11  12  13  14  15  18  17  18  10  20  21  22  23  24  25  2ft  27  28  20  30)  with  conte 

asserting  >  (bat_D  actDl  rangeDl  dayDl) 

Setting  value  of  actDl  to  (act  A)  with  context  =  cycle 

Setting  value  of  rangeDl  to  (range  A  range  B  range  C  range_D  range  E  range_F)  with  context  =  cycle 

Setting  value  of  dayDl  to  (I  2  3  4  5  8)  with  context  =  cycle 

asserting  >  (bat  _D  actD2  rangeD2  dayD2) 

Setting  value  of  actD2  to  (act  A)  with  context  =*  cycle 

Setting  value  of  rangeD2  to  (range  A  range_B  range_C  range_D  range  E  range_F)  with  context  =  cycle 
Setting  value  of  dayD2  to  (28  27  28  20  30)  with  context  =  cycle 


We  can  Inquire  the  database  by  using  the  describe  function.  This  function 
takes  as  an  argument  the  name  of  an  object.  It  echoes  all  the  associated 
variables  and  their  values. 


-> 

(describe  'bat  A) 

actA4  =  (act_B)  cycle  —  cycle 

rangeA4  =  (range  A  range  B  range  C  range_D  range  E  range_F)  cycle  =  cycle 
dayA4  =  (1  2  3  4  5  8)  cycle  =  cycle 
actAS  =  (act_  A)  cycle  =  cycle 

rangeAS  =  (range  A  range_  B  range  C)  cycle  =  cycle 

dayAS  =  (1  23456780  10  II  12  13  14  15  16  17  18  10  20  21  22  23  24  25  28  27  28  20  30)  cycle  =  cycle 
actA2  =  (act_A)  cycle  =  cycle 

rangeA2  =  (range_A  range_B  range_C)  cycle  =  cycle 

dayA2  =  (1  2  3  4  6  6  7  8  0  10  1 1  12  IS  14  15  16  17  18  10  20  21  22  23  24  25  28  27  28  20  30)  cycle  =  cycle 
actAl  =  (act_A)  cycle  =  cycle 

rangeA  I  =  (range  _  A  range  _B  range  _C)  cycle  =  cycle 

dayAl  =  (1  2  3  4  5  8  7  8  0  10  11  12  13  14  15  18  17  18  10  20  21  22  23  24  25  26  27  28  20  30)  cycle  =  cycle 
oil 

->  (describe  'bat  B) 

actBS  =  (act  C)  cycle  =  cycle 

rangeB3  =  (range  A  range  B  range_C  range_D  range_E  range_F)  cycle  =  cycle 
dayBS  =  (26  27  28  20  30)  cycle  =  cycle 
actB2  =  (act_  A)  cycle  =  cycle 
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rangeB2  =  (range_A  range_B  range_C  range_D  range_E  range__F)  cycle  =  cycle 
dayB2  —  (28  27  28  28  SO)  cycle  —  cycle 
aetBl  ■=  (act_B)  cycle  =  cycle 

rangeBl  =  (ringe  A  tmje  B  range_C  range_D  range_E  range_F)  cycle  =  cycle 

dayBl  “(1  23456780  10  11  12  13  18  IS  10  17  18  18  20  21  22  23  24  25  28  27  28  28  30)  cycle  =  cycle 


->  (describe  'bat_C) 

actCS  =  (act_B)  cycle  =  cycle 

rangeCS  =  (range_A  range_B  range_C  range_D  range_E  range_F)  cycle  =  cycle 

dayC3  “(1  2  3  4  5  8  7  8  8  10  11  12  13  14  15  18  17  18  18  20  21  22  23  24  25  26  27  28  28  30)  cycle  =  cycle 

actC2  =  (act_B)  cycle  =  cycle 

rangeC2  =  (range_A  range_B  range_C  range_D  range_E  range_F)  cycle  =  cycle 
dayC2  “(1  23458)  cycle  =  cycle 
actCl  =  (act_A)  cycle  =  cycle 

rangeCl  -=  (range_A  range_B  range_C  range_D  range_E  range_F)  cycle  «=  cycle 

dayCl  =  (1  2  3  4  5  6  7  8  8  10  11  12  13  14  15  16  17  18  18  20  21  22  23  24  25  26  27  28  28  30)  cycle  =  cycle 

nil 

->  (describe  ’bat_D) 

actD2  *=  (act_A)  cycle  =  cycle 

rangeD2  =  (range_A  range  B  range_C  range_D  range_E  range_F)  cycle  «=  cycle 
dayD2  =  (26  27  28  20  30)  cycle  =  cycle 
actDl  “  (act_A)  cycle  =  cycle 

rangeDl  =  (range_A  range  B  range_C  range_D  range  E  range_F)  cycle  =  cycle 

dayDl  =(1  2  3  4  5  6)  cycle  =  cycle 

nil 


Having  loaded  all  the  data  we  now  Issue  the  command:  (search)  We  do  not 
have  to  load  the  constraints  yet,  the  search  routine  will  do  that  automatically. 

The  computer  starts  off  In  the  propagation  state.  Whenever  a  constraint  is 
used  It  echoes  the  fact  that  it  is  setting  the  value  of  a  variable  to  some  new 
value  set.  The  computer  echos  "USING  CONSTRAINT:”  followed  by  the 
name  of  the  constraint. 

->  (search) 

[load  constraints.!] 

USING  CONSTRAINT:  C8 

Setting  value  of  dayD2  to  (26  27  28  30)  with  context  =  cycle 

Setting  value  of  dayDl  to  (2  3  4  5)  with  context  =  cycle 

Setting  value  of  dayCS  to  (2  3  4  5  7  8  8  10  11  12  13  15  16  17  18  18  20  21  23  24  25  26  27  28  30)  with  context  =  cycle 

Setting  value  of  dayC2  to  (2  3  4  5)  with  context  — “  cycle 

Setting  value  of  dayCl  to  (2  3  4  6  7  8  8  10  II  12  13  15  16  17  18  10  20  21  23  24  25  26  27  28  30)  with  context  =  cycle 

Setting  value  of  dayB3  to  (28  27  28  SO)  with  context  =  cycle 

Setting  value  of  dayB2  to  (26  27  28  30)  with  context  =  cycle 

Setting  value  of  dayBl  to  (2  3  4  6  7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  26  27  28  SO)  with  context  =  cycle 
Setting  value  of  dayA4  to  (2  3  4  5)  with  context  =  cycle 
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Setting  value  of  dayA3  to  (2  3  4  5  7  8  9  10  1 1  12  13  IS  18  17  18  18  20  21  23  21  25  2#  27  28  30)  witli  run  text  —  eyrie 

Setting  value  of  dayA2  to  (2  3  1  5  7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  28  27  28  30)  with  context  =  cycle 

Setting  value  of  dayAl  to  (2  3  4  5  7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  28  27  28  30)  with  context  =  eyrie 

USING  CONSTRAINT:  C8  one 

Setting  value  of  dayA3  to  (7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  28  27  28  30)  with  context  =  cycle 

Setting  value  of  dayA2  to  (7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25)  with  context  =  cycle 

Setting  value  of  dayAl  to  (2  3  4  5  7  8  8  10  11  12  13  15  16  17  18  18  20)  with  context  =  cycle 
USING  CONSTRAINT:  C4_  three 

Setting  value  of  rangeB3  to  (range  B)  with  context  =  cycle 
USING  CONSTRAINT:  C4_lwo 

Setting  value  of  rangeC3  to  (range  C)  with  context  =  cycle 

Setting  value  of  rangeC2  to  (range  C)  with  context  =  cycle 

Setting  value  of  rangeBl  to  (range _C)  with  context  =  cycle 

Settiug  value  of  rangeA4  to  (range  C)  with  context  =  cycle 

USING  CONSTRAINT:  C4  _one 

Setting  value  of  rangeD2  to  (range  A  range  _B)  with  context  —  cycle 

Setting  value  of  rangeDl  to  (range  A  range  _B)  with  context  =  cycle 

Setting  value  of  ranged  to  (range_  A  rangeB)  with  context  =  cycle 
Setting  value  of  rangeB2  to  (range  A  range _B)  with  context  =  cycle 
Setting  value  of  rangeA3  to  (range  A  range  _  B)  with  context  =  cycle 

Setting  value  of  rangeA2  to  (range  A  range  _B)  with  context  =  cycle 

Setting  value  of  rangeAl  to  (range  A  range  _B)  with  context  =  cycle 

USING  CONSTRAINT:  C6_one 

Setting  value  of  day  A3  to  (12  13  15  16  17  18  18  20  21  23  24  25  26  27  28  30)  with  context  «=  cycle 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  rangeD2  to  (range _B)  with  context  =  cycleO 
Setting  the  value  of  rangeD2  to  (range  A)  with  context  cyclel 
PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  rangeDl  to  (range  _B)  with  context  —  cycle2 
Setting  the  value  of  rangeDl  to  (range  A)  with  context  «=  cycles 
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PROPAGATION  COMPLETE 


BRANCHING  ... 

Setting  the  value  of  rangeCI  to  (range_B)  with  context  =  cycled 

Setting  the  value  of  rangeCI  to  (range_A)  with  context  =  cycles 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  rangeB2  to  (range  _B)  with  context  =  cycle# 

Setting  the  value  of  rangeB2  to  (range_A)  with  context  “  cycle7 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  rangeAS  to  (range  B)  with  context  =  cycle8 

Setting  the  value  of  rangeAS  to  (range  d)  with  context  cycle# 

BRANCHING  ... 

Setting  the  value  of  rangeA2  to  (range  B)  with  context  •“  cyclelO 

Setting  the  value  of  rangeA2  to  (range_A)  with  context  «=  cyclell 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  rangeAl  to  (range  B)  with  context  ««  cycle!# 

Setting  the  value  of  rangeAl  to  (range_A)  with  context  «=  cyclelS 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayD2  to  (30)  with  context  =  cyclel4 

Setting  the  value  of  dayD2  to  (29)  with  context  •*  cyclel5 

Setting  the  value  of  dayD2  to  (27)  with  context  —  cyclelS 

Setting  the  value  of  dayD2  to  (2S)  with  context  «  cyclel7 

Setting  value  of  dayCl  to  (2  3  4  5  7  8  9  10  11  12  13  IS  18  17  18  19  20  21  23  24  25  27  29  30)  with  context  =  cycle  17 
Setting  value  of  dayB2  to  (27  29  30)  with  context  cycle!7 

Setting  value  of  dayAS  to  (12  13  IS  1#  17  18  19  20  21  23  24  25  27  29  30)  with  context  —  cyclel7 
USING  CONSTRAINT:  C7_aux_aux 
USING  CONSTRAINT:  C7_aux 

Setting  value  of  dayCS  to  (2  3  4  5  7  8  9  10  II  12  13  IS  IS  17  18  19  20  21  23  24  25  27  29  30)  with  context  —  cyclel7 


Selling  value  of  dayBl  to  (2  3  4  5  7  8  6  10  1 1  12  13  15  18  17  18  IS  20  21  23  24  25  27  28  30)  with  context  =  eyrle!7 


PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayB2  to  (30)  with  context  =  cyclel8 
Setting  the  value  of  dayB2  to  (20)  with  context  =  cyclelO 
Setting  the  value  of  dayB2  to  (27)  with  context  =  cycle20 

USING  CONSTRAINT,  cl  aux 

Setting  value  of  dayB3  to  (28  20  30)  with  context  =  cyele20 

Setting  value  of  dayBl  to  (2  3  4  5  7  8  8  10  1 1  12  13  15  18  17  18  10  20  21  23  24  25  28  30)  with  context  =  cycle20 
USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (2  3  4  5  7  8  0  10  11  12  13  15  18  17  18  10  20  21  23  24  25  20  30)  with  context  =  cyclc20 

Setting  value  of  dayA3  to  (12  13  15  18  17  18  10  20  21  23  24  25  20  30)  with  context  —  cycle20 

USING  CONSTRAINT:  C7  aux 

Setting  value  of  dayC3  to  (2  3  4  5  7  8  0  10  1 1  12  13  15  18  17  18  10  20  21  23  24  25  20  30)  with  context  =  cyrle20 
PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayB3  to  (30)  with  context  =  cycle21 
Setting  llie  value  of  dayB3  to  (20)  with  context  =  cycle22 
Setting  the  value  of  dayB3  to  (28)  with  context  =  cycle23 
PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayDI  to  (5)  with  context  —  cycle24 
Setting  the  value  of  dayDI  to  (4)  with  context  =  cycle25 
Setting  the  value  of  dayDI  to  (3)  with  context  =  cycle28 
Setting  the  value  of  dayDI  to  (2)  with  context  =  cycle27 
USING  CONSTRAINT:  C2  one 

Setting  value  of  dayCl  to  (3  4  5  7  8  0  10  1 1  12  13  15  18  17  18  10  20  21  23  24  25  20  30)  with  context  —  cycle27 

Setting  value  of  dayAl  to  (3  4  5  7  8  8  10  II  12  13  15  18  17  18  10  20)  with  context  =  cycle27 

USING  CONSTRAINT:  C7_  aux 

Setting  value  of  dayC3  to  (3  4  5  7  8  0  10  11  12  13  15  18  17  18  10  20  21  23  24  25  20  30)  with  context  =  cycle27 
Setting  value  of  dayC2  to  (3  4  5)  with  context  =  cycle27 
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Setting  value  of  dayBl  to  (3  4  S  7  8  B  10  1J  12  IS  15  18  17  18  lfi  20  21  23  24  25  28  30)  with  context  =  cycle27 
Setting  value  of  dayA4  to  (3  4  5)  with  context  =■  cycle27 
USING  CONSTRAINT:  C8_one 

Setting  value  of  dayA2  to  {8  8  10  11  12  13  15  16  17  18  18  20  21  23  24  25)  with  context  =  cycle27 
PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayC2  to  (5)  with  context  «•  cyde28 
Setting  the  value  of  d»yC2  to  (4)  with  context  ■=  cycle28 
Setting  the  value  of  dayC2  to  (3)  with  context  — ■  cycleSO 
USING  CONSTRAINT:  C6_one 

Setting  value  of  day  A3  to  (13  15  16  17  18  18  20  21  23  24  25  28  30)  with  context  =  cycle30 
USING  CONSTRAINT:  cl_aux 

Setting  value  of  dayCS  to  (4  5  7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  28  30)  with  context  =  cycle30 
Setting  value  of  dayCl  to  (4  5  7  8  0  10  11  12  13  15  16  17  18  10  20  21  23  24  25  20  30)  with  context  =  cycle30 
USING  CONSTRAINT:  C2_one 

Setting  value  of  dayBl  to  (4  5  7  8  8  10  11  12  13  15  16  17  18  18  20  21  23  24  25  28  30)  with  context  —  cycle30 
Setting  value  of  dayA4  to  (4  5)  with  context  =  cycleSO 
USING  CONSTRAINT:  C3_aux 

Setting  value  of  dayCS  to  (5  7  8  0  10  11  12  13  15  16  17  18  18  20  21  23  24  25  20  30)  with  context  «=  cycleSO 
Setting  value  of  dayCl  to  (5  7  8  8  10  11  12  13  15  16  17  18  18  20  21  23  24  25  28  30)  with  context  =  cycle30 
PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayA4  to  (5)  with  context  -*  cycleSl 
Setting  the  value  of  dayA4  to  (4)  with  context  cycle32 
USING  CONSTRAINT:  cl  _  aux 

Setting  value  of  dayAi  to  (3  5  7  8  0  10  11  12  13  15  16  17  18  18  20)  with  context  —  cycle32 
USING  CONSTRAINT:  C2_one 

Setting  value  of  dayBl  to  (S  7  8  0  10  II  12  18  1$  18  17  18  10  20  21  23  24  25  28  30)  with  context  »  cycie32 
USING  CONSTRAINT:  C3_aux 

Setting  value  of  dayAi  to  (3  7  8  0  10  11  12  13  15  16  17  18  18  20)  with  context  «  cycle32 

PROPAGATION  COMPLETE 


BRANCHING  ... 


Setting  the  value  of  day  AS  to  (30)  with  context  =  cycle33 

Setting  the  value  of  dayA3  to  (28)  with  context  =  cycle34 

Setting  the  value  of  day  A3  to  (25)  with  context  =  cycle35 

Setting  the  value  of  dayAS  to  (24)  with  context  =  cycleSfl 

Setting  the  value  of  dayA3  to  (23)  with  context  =  cycle37 

Setting  the  value  of  day  A3  to  (21)  with  context  =  cycle38 

Setting  the  value  of  day  A3  to  (20)  with  context  =  cycle30 

Setting  the  value  of  dayAS  to  (18)  with  context  =  cycle40 

Setting  the  value  of  dayA3  to  (18)  with  context  =  cycle41 

Setting  the  value  of  day  A3  to  (17)  with  context  =  cyclc42 

Setting  the  value  of  day  A3  to  (18)  with  context  =  cycle43 

Setting  the  value  of  day  A3  to  (15)  with  context  <=  cycle44 
Setting  the  value  of  day  A3  to  (13)  with  context  =  cycle45 
USING  CONSTRAINT:  C8_one 
Setting  value  of  dayA2  to  (8)  with  context  cycle45 

Setting  value  of  dayAl  to  (3)  with  context  =  cycle45 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  28  30)  with  context  =  cycle45 
USING  CONSTRAINT:  C2  _  two 
USING  CONSTRAINT:  C2  one 

Setting  value  of  dayCl  to  (5  7  8  10  11  12  15  18  17  18  18  20  21  23  24  25  28  30)  with  context  —  cycle45 
USING  CONSTRAINT:  C7_aux 

Setting  value  of  dayCS  to  (5  7  8  8  10  II  12  15  18  17  18  18  20  21  23  24  25  28  30)  with  context  —  cycle45 

Setting  value  of  dayBI  to  (5  7  8  0  10  II  12  15  18  17  18  18  20  21  23  24  25  28  30)  with  context  —  cyclc45 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayCl  to  (30)  with  context  «■  eycle48 
Setting  the  value  of  dayCl  to  (28)  with  context  ™  cycle47 
Setting  the  value  of  dayCl  to  (25)  with  context  ■=■  cycle48 
Setting  the  value  of  dayCl  to  (24)  with  context  »»  cycle48 
Setting  the  value  of  dayCl  to  (23)  with  context  cyc!e50 
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Setting  the  value  of  dayCl  to  (21)  with  context  =  cyc!e5I 
Setting  the  value  of  dayCl  to  (20)  with  context  =  cycleS2 
Setting  the  value  of  dayCl  to  (10)  with  context  =  cycle53 
Setting  the  value  of  dayCl  to  (18)  with  context  =  cycle54 
Setting  the  value  of  dayCl  to  (17)  with  context  «=  cycleSS 
Setting  the  value  of  dayCl  to  (10)  with  context  =  cycleSO 
Setting  the  value  of  dayCl  to  (IS)  with  context  =  cycle57 
Setting  the  value  of  dayCl  to  (12)  with  context  =  cycle58 
Setting  the  value  of  dayCl  to  (11)  with  context  =  cycle50 
Setting  the  value  of  dayCl  to  (10)  with  context  **  cycleSO 
Setting  the  value  of  dayCl  to  (S)  with  context  «=  cycleSl 
Setting  the  value  of  dayCl  to  (7)  with  context  >=  cycle62 
Setting  the  value  of  dayCl  to  (5)  with  context  =  cycleSS 
USING  CONSTRAINT:  cl  aux 

Setting  value  of  dayC3  to  (7  8  0  10  II  12  15  16  17  18  10  20  21  23  24  25  20  30)  with  context  =  cycle63 

USING  CONSTRAINT:  C7  aux 
BACKTRACKING...  purging  context  cycleSS 

Here  la  the  first  BACKTRACKING  point.  It  found  a  problem  at  constraint 
C7_aux.  It  does  a  chronological  BACKTRACKING  by  just  purging  the 
context  cycleftS. 

We  shall  break  the  program  to  look  at  the  current  state  of  the  problem.  It 
would  be  Interesting  to  find  out  the  cause  of  the  failure. 

USING  CONSTRAINT:  cl  _  aux 

Setting  value  of  dayCS  to  (5  8  0  10  11  12  15  IS  17  18  ID  20  21  23  24  25  20  30)  with  context  =  cycleS2 
USING  CONSTRAINT:  C7_aux 

BACKTRACKING...  purging  context  cycle62 

[load  constraint*. I] 

USING  CONSTRAINT:  C8 

*C 

Interrupt: 

Break  nil 

<I>:  (describe  ’bat_A) 
actA4  ■»  (act_B)  cycle  cycle 
rangeAl  *  (range_C)  cycle  »  cycle 
dayA4  —  (4)  cycle  ■*  cycle32 


actA3  =  (act  A)  cycle  =  cycle 
rangeA3  =  (range  A)  cycle  =  cycle# 
day  AS  «=  (13)  cycle  =  cyrle45 
actA2  =  (act  A)  cycle  =  cycle 
rangeA2  =  (range  A)  cycle  —  cyclell 
dayA2  =  (8)  cycle  =  cyrle45 
actAl  =  (act  A)  cycle  =  cycle 
rangeAl  =  (range  A)  cycle  =  cyclel3 
dayAl  =  (3)  cycle  =  cycle-15 
nil 

<1>: 

(describe  'batB  _  B) 
actB3  =  (act  C)  cycle  =  cycle 
rangeBS  =  (range  _B)  cycle  =  cycle 
dayB3  =*  (26)  cycle  =  cycle23 
actB2  =  (act_  A)  cycle  =  cycle 
rangeB2  =  (range  A)  cycle  =  cycle7 
dayB2  =  (27)  cycle  =  cycle20 
actBl  =  (act  B)  cycle  ■=  cycle 
rangeBl  =  (range  C)  cycle  =  cycle 

dayBl  =  (5  7  8  S  10  11  12  15  16  17  18  IS  20  21  23  24  25  29  30)  cycle  =  cyc!e45 
nil 

<1>: 

(describe  'bat  __  C) 

actC3  =  (art  B)  cycle  =  cycle 

rangeC3  —  (range  C)  cycle  =  cycle 

dayC3  ==  (5  7  8  0  10  1 1  12  IS  18  17  18  18  20  21  23  24  2S  2#  30)  cycle  =  cycle45 

actC'2  =  (act  B)  cycle  =  cycle 

rangeC2  =  (range  C)  cycle  =  cycle 

da,vC2  =  (3)  cycle  =  cycle30 

actCI  =  (act_A)  cycle  =  cycle 

rangeCl  =  (range  A)  cycle  =  cycle5 

dayCl  =  (9)  cycle  =  cycle61 

nil 

<1>: 

(describe  'bat  D) 
artD2  «=  (act  A)  cycle  =  cycle 
rangeD2  »=  (range  A)  cycle  =  cyclel 
dayD2  =  (26)  cycle  =  cyclel7 
actDl  *=  (act  _  A)  cycle  =  cycle 
rangeDI  =  (range  A)  cycle  =  cycle3 
dayPl  =  (2)  cycle  =  cycle27 
nil 


We  see  that  the  backup  was  Initiated  by  using  the  constraint  C7_aux.  This 
constraint  says  that  if  activity  act_ A  is  scheduled  on  range_A  on  any  day  'x'. 
Then  range _C  will  be  unsafe  to  use  on  that  day. 

We  see  that 

rangeAl  =  range  A 

actAl  =  act_  A 

dayAl  =  (3)  Cycle  =  45 

rangeC2  =  range  C 

dayCS  =  (3)  Cycle  =  30 
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With  the  current  context,  however,  Is  cycleSl.  The  stupid  program  does  not 
realise  that  It  should  backtrack  to  cycle45  to  get  rid  of  the  problem.  It  will 
backtrack  and  try  to  propagate  20  times.  I  hereby  force  the  backup  just  to 
save  time.  This  Is  the  problem  In  chronological  BACKTRACKING. 

I  take  the  liberty  of  backing  up  to  cyde45....  This  is  done  despite  the  fact 
the  program  will  (eventually)  reach  do  the  same. 

<1>:  (loop  for  x  from  4S  to  SI  do  (backtrack)) 

BACKTRACKING...  purging  context  cycleSl 

BACKTRACKING...  purging  context  cycleftO 

BACKTRACKING...  purging  context  cycleSO 


BACKTRACKING...  purging  context  cycleS8 


BACKTRACKING...  purging  context  cycle87 


BACKTRACKING...  purging  context  cycle58 


BACKTRACKING...  purging  context  cycleSS 


BACKTRACKING...  purging  context  cycleSS 


BACKTRACKING...  purging  context  cycle5J 


BACKTRACKING...  purging  context  cycleS2 


BACKTRACKING...  purging  context  cycleSl 


BACKTRACKING...  purging  context  eycleSO 


BACKTRACKING...  purging  context  cycletB 
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BACKTRACKING...  purging  context  cycle48 


1 

i 

f 

I 

J 


f 

4 


1 

] 


BACKTRACKING...  purging  context  cycled? 


BACKTRACKING...  purging  context  cycle46 


BACKTRACKING...  purging  context  cycle45 
nil 

<1>:  (reset) 

(Return  to  top  level) 

->  (describe  ’bat_A) 
actA4  =  (act_  B)  cycle  =  cycle 
rangeA4  =  (range_C)  cycle  =  cycle 
dayA4  ==  (4)  cycle  =  cycle32 
act  A3  =  (act  A)  cycle  =  cycle 
rangeA3  =  (range  A)  cycle  =  cyde9 
dayA3  =  (15)  cycle  =  cycle44 
actA2  =  (act_A)  cycle  =  cycle 
rangeA2  =  (range  A)  cycle  =  cycle  II 

dayA2  =  (8  0  10  II  12  13  15  18  17  18  18  20  21  23  24  25)  cycle  =  cycle27 
actAl  «=  (act_A)  cycle  “  cycle 
rangeAl  =  (range_A)  cycle  =»=  cyclelS 

dayAl  —  (3  7  8  8  10  11  12  13  15  18  17  18  18  20)  cycle  *»  cyrleS2 
nil 
-> 


(describe  ’bat_B) 
actB3  =  (act_C)  cycle  =  cycle 
rangeB3  =  (range  _B)  cycle  =  cycle 
dayB3  •=  (28)  cycle  —  cycle23 
actB2  =  (act_  A)  cycle  =  cycle 
rangeB2  =  (range  A)  cycle  *=  cycle7 
dayB2  *=  (27)  cycle  =  cycle20 
actBl  *=  (act_B)  cycle  «■*  cycle 
rangeBl  =  (range  C)  cycle  =  cycle 

dayBI  —  (5  7  8  8  10  11  12  13  IS  18  17  18  18  20  21  23  24  25  28  30)  cycle  —  ryc)e32 
nil 

->  (describe  ’bat_C) 

actC3  *=  (act_  B)  cycle  =  cycle 

ran  geC3  =  (range  _C)  cycle  =  cycle 

dayC3  =  (5  7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  28  30)  cycle  **  cycle30 

actC2  *=  (act_B)  cycle  =  cycle 

rangef'2  =  (range  C)  cycle  “  cycle 

dayC2  =  (3)  cycle  =  cycleSO 

actCl  (act  A)  cycle  •»  cycle 

rangeCl  “  (range_A)  cycle  *  cycles 

dayCl  —  (5  7  8  8  10  11  12  13  15  18  17  18  18  20  21  23  24  25  28  30)  cycle  —  cycleSO 
nil 
-> 

(describe  ’bat  _  D) 
actD2  <=  (act_A)  cycle  =  cycle 
rangeD2  «>  (range_A)  cycle  *  cycle  I 
dayD2  *=  (26)  cycle  *  cycle!7 
actDl  <■»  (act_A)  cycle  «=  cycle 
rangeDl  -»  (range  _  A)  cycle  »■  cycle3 

dayDl  »  (2)  cycle  «  cycle27 
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nil 

->  (search) 

USING  CONSTRAINT:  C6_one 

Setting  value  of  dayA2  to  (8  9  10)  with  context  =  cycled! 

Setting  value  of  dayAl  to  (3)  with  context  «  cycled! 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  8  9  10  11  12  13  16  17  18  19  20  21  23  2!  25  20  30)  with  context  =  cycled! 
USING  CONSTRAINT:  C7_aux 

Setting  value  of  dayCS  to  (5  7  8  9  10  11  12  13  18  17  18  19  20  21  23  2!  25  29  30)  with  context  «=  cycled! 

Setting  value  of  dayBt  to  (5  7  8  9  10  11  12  13  16  17  18  10  20  21  23  2!  25  29  30)  with  context  =  cycled! 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayA2  to  (10)  with  context  “  cycledS 
Setting  the  value  of  dayA2  to  (9)  with  context  •=»  cycledS 
Setting  the  value  of  dayA2  to  (8)  with  context  •»  cycle!7 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  9  10  11  12  13  16  17  18  19  20  21  23  2!  25  29  30)  with  context  «=  cycle!7 

USING  CONSTRAINT:  C7_aux 
BACKTRACKING...  purging  context  cycle!7 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  8  10  11  12  13  16  17  18  19  20  21  23  2!  25  29  30)  with  context  =  cycledS 

USING  CONSTRAINT:  C7_aux 
BACKTRACKING...  purging  context  cycledS 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  8  9  11  12  13  16  17  18  19  20  21  23  2!  25  29  SO)  with  context  —  cycledS 

USING  CONSTRAINT:  C7_aux 
BACKTRACKING...  purging  context  cycledS 
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USING  CONSTRAINT:  C 7  aux 

BACKTRACKING...  purging  context  cycled 

USING  CONSTRAINT:  C8  one 

Setting  value  of  dayA2  to  (8  #  10  II)  with  context  =  cycle43 
Setting  value  of  dayAl  to  (?)  with  context  «=  eyelet? 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  g  S  10  11  12  13  IS  17  18  IS  20  21  23  24  25  28  30)  with  context  —  cycle43 
USING  CONSTRAINT:  C7_aux 

Setting  value  of  dayC3  to  (S  7  8  0  10  11  12  13  IS  17  18  10  20  21  23  24  25  20  30)  with  context  —  cycle43 
Setting  value  of  dayBl  to  (5  7  8  8  10  II  12  13  IS  17  18  10  20  21  23  24  25  28  30)  with  context  —  cycle43 

USING  CONSTRAINT:  Cl 
PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayA2  to  (ll)  with  context  =  cycle44 
Setting  the  value  of  dayA2  to  (10)  with  context  =  cycle45 
Setting  the  value  of  dayA2  to  (8)  with  context  =  cycle4S 
Setting  the  value  of  dayA2  to  (8)  with  context  =  cycle47 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  8  10  11  12  13  IS  17  18  18  20  21  23  24  25  20  30)  with  context  =  cycle47 
USING  CONSTRAINT.  C7  _aux 

BACKTRACKING...  purging  context  cycle47 
USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  7  8  10  11  12  13  IS  17  18  10  20  21  23  24  25  28  30)  with  context  •=  cycle40 
USING  CONSTRAINT:  C7_aux 
BACKTRACKING...  purging  context  cycle4A 
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USING  CONSTRAINT:  C2_one 

Setting  value  of  day  Cl  to  (5  7  8  8  11  13  IS  IS  17  18  IS  80  21  23  24  2S  28  SO)  with  context  —  eyelets 
USING  CONSTRAINT:  C7_aux 

BACKTRACKING...  purging  context  eyelets 
USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (S  7  8  0  10  12  IS  IS  17  18  18  20  21  23  2t  25  28  SO)  with  context  —  eyclett 
USING  CONSTRAINT:  C7_aux 

BACKTRACKING...  purging  context  eyclett 
USING  CONSTRAINT:  C7_aux 

BACKTRACKING...  purging  context  eyelets 
USING  CONSTRAINT:  C8_one 

Setting  value  of  dayA2  to  (8  8  10  11  12)  with  context  «  cyclet2 
Setting  value  of  dayAl  to  (S  7)  with  context  =“  cyclet2 

USING  CONSTRAINT:  C2_ooe 

Setting  value  of  dayCl  to  (5  7  8  8  10  11  12  IS  IS  IS  18  18  20  21  2S  2t  25  28  SO)  with  context  —  cydet2 
USING  CONSTRAINT:  C2_two 
USING  CONSTRAINT:  C7_aux 

Setting  value  or  dayCS  to  (5  7  8  8  10  11  12  IS  16  IS  18  18  20  21  23  2t  25  28  30)  with  context  =  cyclet2 
Setting  value  of  dayBl  to  (S  7  8  8  10  11  12  IS  IS  18  18  18  20  21  28  24  26  28  30)  with  context  —  cyde42 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayAl  to  (7)  with  context  ■*  eyelets 
Setting  the  value  of  dayAl  to  (S)  with  context  “  eyclett 

USING  CONSTRAINT:  C7_aux 

BACKTRACKING...  purging  context  cydett 
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USING  CONSTRAINT.  CO  one 
Setting  value  of  dayA2  to  (12)  with  context  «=  eyelets 

USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (5  8  8  10  II  12  13  IS  IS  18  IS  20  21  23  24  25  20  30)  with  context  =  cycle43 
USING  CONSTRAINT:  C2_one 

Setting  value  of  dayCl  to  (S  8  8  10  11  13  IS  10  18  18  20  21  23  24  25  28  30)  with  context  =  cycle43 

USING  CONSTRAINT:  C7  aux 

Setting  value  of  dayC3  to  (5  8  8  10  11  12  13  IS  18  18  18  20  21  23  24  25  28  30)  with  context  =  cycle43 

Setting  value  of  dayBl  to  (S  8  0  10  II  12  13  15  18  18  18  20  21  23  24  25  28  30)  with  context  —  cycle43 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayCl  to  (30)  with  context  —  cycle44 
Setting  the  value  of  dayCl  to  (28)  with  context  =  cycle4S 
Setting  the  value  of  dayCl  to  (25)  with  context  =  cyc!e46 
Setting  the  value  of  dayCl  to  (24)  with  context  =  cycte47 
Setting  the  value  of  dayCl  to  (23)  with  context  =  cycle48 
Setting  the  value  of  dayCl  to  (21)  with  context  =  cycle48 
Setting  the  value  of  dayCl  to  (20)  with  context  =  cycle50 
Setting  the  value  of  dayCl  to  (18)  with  context  =  cycleSI 
Setting  the  value  of  dayCl  to  (18)  with  context  «=  cycle52 
Setting  the  value  of  dayCl  to  (18)  with  context  =  cycle53 
Setting  the  value  of  dayCl  to  (15)  with  context  =  cycle54 
Setting  the  value  of  dayCl  to  (13)  with  context  cycte55 
Setting  the  value  of  dayCl  to  (11)  with  context  =»  cyeleSS 
Setting  the  value  of  dayCl  to  (10)  with  context  **  cycle57 
Setting  the  value  of  dayCl  to  (8)  with  context  ■“  cyeleSS 

Setting  the  value  of  dayCl  to  (8)  with  context  =  cyeleSS 

Setting  the  value  of  dayCl  to  (5)  with  context  ■“  cycleBO 

USING  CONSTRAINT:  cl  _  aux 

Setting  value  of  dayC3  to  (8  8  10  II  12  13  15  18  18  18  20  21  23  24  25  28  30)  with  context  *=  cycleSO 
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USING  CONSTRAINT:  C7  aux 


Setting  value  of  dayCS  to  (8  9  10  II  IS  IS  10  18  19  20  21  23  24  25  29  30)  with  context  *=  cycleOO 
Setting  value  of  dayBl  to  (5  8  9  10  11  13  15  18  18  19  20  21  23  24  25  29  30)  with  context  =  cycleOO 


USING  CONSTRAINT:  C7  aux 

Setting  value  of  dayBl  to  (8  9  10  11  13  15  18  1 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayC3  to  (30)  with  context 
Setting  the  value  of  dayCS  to  (29)  with  context 
Setting  the  value  of  dayCS  to  (25)  with  context 
Setting  the  value  of  dayC3  to  (24)  with  context 
Setting  the  value  of  dayC3  to  (23)  with  context 
Setting  the  value  of  dayCS  to  (21)  with  context 
Setting  the  value  of  dayC3  to  (20)  with  context 
Setting  the  value  of  dayC3  to  (IB)  with  context 
Setting  the  value  of  dayCS  to  (18)  with  context 
Setting  the  value  of  dayC3  to  (18)  with  context 
Setting  the  value  of  dayC3  to  (15)  with  context 
Setting  the  value  of  dayC3  to  (13)  with  context 
Setting  the  value  of  dayC3  to  (11)  with  context 
Setting  the  value  of  dayCS  to  (10)  with  context 
Setting  the  value  of  dayC3  to  (0)  with  context  « 
Setting  the  value  of  dayC3  to  (8)  with  context  * 


19  20  21  23  24  25  29  30)  with  context  —  cyclcBO 


**=  cycleOl 
=  cycle82 
=  cycle83 
=  cycle64 
=  cycle65 
=  cycle86 
«=  cycle87 
=  cycle88 
=  cycleOO 
=  cycle70 
•=  cyde71 
«=  cycle72 
"  cyc!e7S 
«  cycle74 
»  cyde75 
■  cycle78 


USING  CONSTRAINT:  C2_one 

Setting  value  of  dayBl  to  (9  10  II  13  IS  18  18  19  20  21  23  24  25  29  30)  with  context  »  cycle76 

PROPAGATION  COMPLETE 
BRANCHING  ... 

Setting  the  value  of  dayBl  to  (30)  with  context  «  cycle77 
Setting  the  value  of  dayBl  to  (29)  with  context  ■«  cycte78 
Setting  the  value  of  dayBl  to  (25)  with  context  “  cycie79 
Setting  the  value  of  dayBl  to  (24)  with  context  mm  cycle80 
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Setting  the  value  of  dayBl  to  (23)  with  context  =  cycled! 
Setting  the  value  of  dayBl  to  (21)  with  context  *=>  cycle82 
Setting  the  value  of  dayBl  to  (20)  with  context  —  cycleSS 
Setting  the  value  of  dayBl  to  (IS)  with  context  «»  cycleSt 
Setting  the  value  of  dayBl  to  (18)  with  context  —  cycle85 
Setting  the  value  of  dayBl  to  (18)  with  context  =  cycle88 
Setting  the  value  of  dayBl  to  (IS)  with  context  —  cycle87 
Setting  the  value  of  dayBl  to  (13)  with  context  >=  cycle88 
Setting  the  value  of  dayBl  to  (11)  with  context  <=  cycleSB 
Setting  the  value  of  dayBl  to  (10)  with  context  =  cycleSO 
Setting  the  value  of  dayBl  to  (8)  with  context  =  cycleBl 


PROPAGATION  COMPLETE 
BRANCHING  ... 

SCHEDULE  GENERATED  SUCCESSFULLY  t 


The  program  has  successfully  terminated.  We  now  look  at  the  results.  The 
four  battalions  are  described  below. 

At  the  end,  we  look  at  the  stack  of  one  of  the  variables.  It  Is  Interesting  to 
note  how  the  value  of  dayAl  changed  from  one  context  to  another.  Note  that 
the  cycle  numbers  jump  from  nil  to  27  to  42. 


->  (describe  'bat  A) 
actA4  =  (act_B)  cycle  =  cycle 
rangeA4  =  (range  _C)  cycle  =  cycle 

dayA4  «=  (4)  cycle  «=  cycle32 
actA3  =  (act_A)  cycle  ■*=  cycle 
rangeA3  =  (range  A)  cycle  cycles 
dayA3  *=  (17)  cycle  —  cycle42 
actA2  «  (act_A)  cycle  «=  cycle 
rangeA2  =  (range_  A)  cycle  =  cycle  1 1 

dayA2  —  (12)  cycle  ■»  cycle4S 
actAl  “  (act_A)  cycle  »  cycle 
rangeAl  “  (range _  A)  cycle  «  cyclelS 
dayAl  «■  (7)  cycle  «=  cycle43 
nil 

->  (describe  ’bat_B) 
actBS  *■  (act_C)  cycle  ■»  cycle 
rangeBS  «  (range _B)  cycle  =  cycle 
dayBS  —  (28)  cycle  ■“  cycle23 
actB2  *  (act_A)  cycle  ■»  cycle 
rsngeB2  ■»  (range  _  A)  cycle  «  cycle7 
dayB2  —  (27)  cycle  —  cycle20 
aclBI  “  (act_B)  cycle  **  cycle 
rsngeBl  (range_C)  cycle  *  cycle 
dayBl  —  (8)  cycle  —  cycleSI 
nil 
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->  (describe  'bat_C) 
actC3  ■=  (act_B)  cycle  =  cycle 
raDfeCS  =  (range  _C)  cycle  =  cycle 
dtyC3  =  (8)  cycle  *=  cycle76 
actC2  «=  (act_B)  cycle  =  cycle 
raogeC2  ■=  (range_C)  cycle  «  cycle 
dayC2  =  (3)  cycle  —  cycleSO 
actCl  *■  (act_A)  cycle  =  cycle 
rangeCi  *=  (range  _  A)  cycle  «  cycles 

dayCI  (5)  cycle  “  cycle#0 
nil 
-> 

(describe  ’bat_D) 
actD2  =  (act_A)  cycle  =  cycle 
rangeD2  =  (range_A)  cycle  =  cyclel 
dayD2  «=  (26)  cycle  =  cyclel7 
actDI  =  (*ct_  A)  cycle  =  cycle 
rangeDI  «=  (range_A)  cycle  «=  cycles 
dayDl  «=  (2)  cycle  =■=  cycle27 
nil 

->  (get  'dayDl  'values  () 

nil 

t 


->  (apply  ’pp  (get  'dayA2  'values)) 

(cycle  13  (12)) 

(cycle!2  (8  6  10  11  12)) 

(cycle27  (8  0  10  11  12  13  IS  18  17  18  IS  20  21  23  24  25)) 

(cycle  (7  8  0  10  11  12  13  IS  16  17  18  IS  20  21  23  24  2S)) 

(cycle  (2  3  4  5  7  8  S  10  11  12  13  15  16  17  18  IS  20  21  23  24  25  26  27  20  30)) 
(cycle  (1  2  3  4  5  7  8  8  10  11  12  13  15  16  17  18  10  20  21  23  24  25  26  27  28  30)) 
cycles  1 


hera%  'D  script  done  on  Wed  May  8  12:03:22  1985 
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